Attempt to emulate subclasses in Haskell, am I reinventing the wheel?
I've linked to an ugly attempt to emulate subclasses in Haskell, and I'm wondering if anyone has done what I have perhaps in a cleaner way. Firstly, the code is here: http://ideone.com/znHfSG To explain what I've done, I first thought that a "method" basically takes some "input" (which I've called "i"), an object (which I've called "c" for class) and returns some output "o" and a potentially modified object "c". I've captured this behaviour in the badly named class "C". I've then made a class "User", with methods "getFirstName" and "putFirstName" and defined them appropriately. Furthermore, I've then made a data type "Age", and then "ExtendedUser" which combines "User" with "Age". At this point, I can still call "getFirstName" and "putFirstName" on "ExtendedUser", as would be hoped. I also defined "getAge", which naturally works on ExtendedUser. Furthermore, I can override "getFirstName" on "ExtendedUser", which I have done to instead return a capitalised version. Is what I've done of any practical use? And has someone done it better than me?
On 20-04-2015 20:01, Clinton Mead wrote:
I've linked to an ugly attempt to emulate subclasses in Haskell, and I'm wondering if anyone has done what I have perhaps in a cleaner way.
Well, I would generally advise against trying to emulate a flawed concept in the first place. "OverlappingInstances" and "UndecidableInstances" are a red flag unless you know *exactly* what you are doing. A much better way (IMO, of course) is to use either 1) normal aggregation (that's the simpl{e,istic} answer), at the cost of some boilerplate. If the boilerplate exceeds practicality, I would look at 2) extensible records/row types as in e.g. "vinyl" Regards,
On Apr 20, 2015 2:26 PM, "Bardur Arantsson"
Well, I would generally advise against trying to emulate a flawed concept in the first place. "OverlappingInstances" and "UndecidableInstances" are a red flag unless you know *exactly* what you are doing.
While I completely agree about OverlappingInstances, I completely disagree about UndecidableInstances. Most of the time, that's only needed because the termination check for FlexibleInstances and FlexibleContexts is too primitive.
Don't do this. It isn't a "bad" idea, it's just that you're not using the
language to its full potential, and will end up with a lot of annoying (and
not quite trivial) boilerplate.
Read 'Data types a la carte'.[1] There really ought to be a "standard"
(even if unofficial) library to do open data types, but rolling your own is
really easy.
[1]: http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf
On Mon, Apr 20, 2015 at 11:01 AM, Clinton Mead
I've linked to an ugly attempt to emulate subclasses in Haskell, and I'm wondering if anyone has done what I have perhaps in a cleaner way.
Firstly, the code is here: http://ideone.com/znHfSG
To explain what I've done, I first thought that a "method" basically takes some "input" (which I've called "i"), an object (which I've called "c" for class) and returns some output "o" and a potentially modified object "c". I've captured this behaviour in the badly named class "C".
I've then made a class "User", with methods "getFirstName" and "putFirstName" and defined them appropriately.
Furthermore, I've then made a data type "Age", and then "ExtendedUser" which combines "User" with "Age".
At this point, I can still call "getFirstName" and "putFirstName" on "ExtendedUser", as would be hoped.
I also defined "getAge", which naturally works on ExtendedUser.
Furthermore, I can override "getFirstName" on "ExtendedUser", which I have done to instead return a capitalised version.
Is what I've done of any practical use? And has someone done it better than me?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (4)
-
Alexander Solla -
Bardur Arantsson -
Clinton Mead -
David Feuer