Hi, In oops, one can do reuse code by extending a parent class. What is the equivalent in Haskell? Regards, Kashyap
On 13 Dec 2010, at 17:16, C K Kashyap wrote:
In oops, one can do reuse code by extending a parent class. What is the equivalent in Haskell?
There isn't an equivalent as Haskell doesn't have classes (type classes are different). There's other ways to do things, but without knowing what you're doing it's difficult to point to anything.
In OO languages I try not to use inheritance just because I want
re-use - I tend to lean more towards having an instance of class A
contain or wrap around an instance of class B - I will only use
inheritance if A truly is a more specific version of B. Even then I
try to make sure there aren't clearer ways of expressing what I want.
This approach applies perfectly well to types in Haskell - compound
types can be composed of values of other types.
But there is not a way to easily say (in Haskell) "type A is
everything that type B is plus these other things here ...". Haskell
is not an OO language.
Antoine
On Mon, Dec 13, 2010 at 11:16 AM, C K Kashyap
Hi, In oops, one can do reuse code by extending a parent class. What is the equivalent in Haskell? Regards, Kashyap
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
But there is not a way to easily say (in Haskell) "type A is everything that type B is plus these other things here ...". Haskell is not an OO language.
This captures what I had in mind. Using compound types seems ok but I'd still need to do some mechanical stuff if I had to provide a function that works on the compound type which is actually defined for a component type. If I understand you right .. you'd build a 'Man' type and 'Woman' type by using a 'Person' type. Lets say, there is a function called getName that is Person -> String I'd have to mechanically define a function getName :: Man -> String - that extracts the person inside and calls getName on it - did I understand it right? Or would you typically write extract functions that'll return the components and then the user could call the method on the component? As in .... getPerson :: Man -> Person ... then call getName on that. How do you deal with situations like that?
On Mon, Dec 13, 2010 at 9:10 PM, C K Kashyap
But there is not a way to easily say (in Haskell) "type A is everything that type B is plus these other things here ...". Haskell is not an OO language.
This captures what I had in mind. Using compound types seems ok but I'd still need to do some mechanical stuff if I had to provide a function that works on the compound type which is actually defined for a component type.
If I understand you right .. you'd build a 'Man' type and 'Woman' type by using a 'Person' type. Lets say, there is a function called getName that is Person -> String I'd have to mechanically define a function getName :: Man -> String - that extracts the person inside and calls getName on it - did I understand it right? Or would you typically write extract functions that'll return the components and then the user could call the method on the component? As in .... getPerson :: Man -> Person ... then call getName on that.
How do you deal with situations like that?
Well, in this case I might just have a person type with a 'gender' field :-) Then I get the polymorphism and code-reuse for free! But what you're talking about is something that OO-style programming is particularly aligned towards, and functional programming generally is not. One thing people do is use type-classes - this would be a bit like having 'Car' and 'Truck' implement the same interface. The simple building blocks would be duplicated, but the complex application-level functionality could be written against the typeclass. Another approach is with functional lenses - these are libraries that aim to make updating complex compound types easier. Off the top of my head I know of fclabels[1], but I know there are others. If you're interested in this approach you might be able to email the -cafe mailing list to ask for more. Is there a particular problem you're trying to solve? we might be able to take the conversation in a less speculative direction. Antoine [1] http://hackage.haskell.org/package/fclabels
Thanks Antoine,
Is there a particular problem you're trying to solve? we might be able to take the conversation in a less speculative direction.
At this point its academic ... I have programmed in OOPS for a long time so, I just wanted to understand how one would go around something like that in Haskell. I came across something called the expression problem and it talks about "open data type" - is this the solution? Regards, Kashyap
You might be interested in Oleg's paper Haskell's Overlooked Object
Systemhttp://homepages.cwi.nl/%7Eralf/OOHaskell/code.html,
although programming in an object-oriented style is neither elegant nor
idiomatic Haskell. Aside from the actual embedding of an object-oriented
language inside Haskell, the main benefit of the paper is the opening survey
of approaches to object-oriented style programming in Haskell. Not
surprisingly, however, encapsulation and subtyping are the most difficult
concepts from object-oriented languages to capture with Haskell type classes
and algebraic data types.
On Tue, Dec 14, 2010 at 7:25 PM, C K Kashyap
Thanks Antoine,
Is there a particular problem you're trying to solve? we might be able to take the conversation in a less speculative direction.
At this point its academic ... I have programmed in OOPS for a long time so, I just wanted to understand how one would go around something like that in Haskell.
I came across something called the expression problem and it talks about "open data type" - is this the solution?
Regards, Kashyap
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On 14 Dec 2010, at 03:10, C K Kashyap wrote:
If I understand you right .. you'd build a 'Man' type and 'Woman' type by using a 'Person' type. Lets say, there is a function called getName that is Person -> String
In this case you can just make a new data type:
data Person = Man {name :: String, age :: Int} | Woman {name :: String}
marry :: Person -> Person -> String
marry (Man m _) (Woman w) = m ++ ", " ++ w ++ ", I know pronounce you Man and Wife"
marry a@(Woman _) b@(Man _ _) = (name b) ++ ", " ++ (name a) ++ ", I know pronounce you Man and Wife"
marry _ _ = error "Not in these parts!"
The clumsy second line is just to show the function
I'm afraid that apologies and humor did not make you seem less "crude," as
you put it, and your language is too apt to be misunderstood by homosexuals
and women as unwelcoming. So please exercise more care when posting.
On Mon, Dec 20, 2010 at 8:18 AM, Paul Sargent
On 14 Dec 2010, at 03:10, C K Kashyap wrote:
If I understand you right .. you'd build a 'Man' type and 'Woman' type by using a 'Person' type. Lets say, there is a function called getName that is Person -> String
In this case you can just make a new data type:
data Person = Man {name :: String, age :: Int} | Woman {name :: String}
marry :: Person -> Person -> String marry (Man m _) (Woman w) = m ++ ", " ++ w ++ ", I know pronounce you Man and Wife" marry a@(Woman _) b@(Man _ _) = (name b) ++ ", " ++ (name a) ++ ", I know pronounce you Man and Wife" marry _ _ = error "Not in these parts!"
The clumsy second line is just to show the function
String> which accesses the name of both men and women. The function "age" also takes a Person as it's argument, but in this case, if you ask a Woman her age things won't end well.
(..and forgive the example. I was finding it hard to come up with something that would be different for men and women without getting crude.)
This isn't the same as the classes you're describing in OO land though. Here, Man and Woman are data constructor functions which both return the type Person. There's no inheritance here, so it's *not* possible to have a Mammal data type of which Person's are a member, and so by extension Man & Woman.
Man and Woman are *not* data types themselves, so I can't write a function
Person>. I'd have to write a Person> and fail if it was passed a Man. I personally find this type of construct very useful, but you just have to be careful to make sure you check to make sure an item can support the functions you want before calling them (e.g. 'age' above). It's not caught by the type checker at compile time, so it'll only be caught at run time and it causes an exception.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On 20 Dec 2010, at 15:06, Richard Mittel wrote:
I'm afraid that apologies and humor did not make you seem less "crude," as you put it, and your language is too apt to be misunderstood by homosexuals and women as unwelcoming. So please exercise more care when posting.
I obviously badly judged the tone of my previous mail, so I want to publicly apologise for it. There was no ill-intent behind it to any group of people, and I didn't mean it as a commentary on what I believed to be right or wrong, more just what law makers seem to be prescribing in certain parts of the world. I have a feeling that some malice was attributed to it that, truly / honestly isn't there. Just a badly made joke on sensitive ground. Obviously not suitable for the list. Even if I only offended one person, that one too many. Lesson learned. Sorry.
2010/12/21 Paul Sargent
On 20 Dec 2010, at 15:06, Richard Mittel wrote:
I'm afraid that apologies and humor did not make you seem less "crude," as you put it, and your language is too apt to be misunderstood by homosexuals and women as unwelcoming. So please exercise more care when posting.
I obviously badly judged the tone of my previous mail, so I want to publicly apologise for it. There was
I fail to see where Paul's email was offensive enough that an apology was needed. At worst, if there was something in bad taste, I think one can give the author the benefit of the doubt unless he repeately posts in bad taste. I also think that if we should care for all the things that could be misunderstood, then it might not be worth it trying to contribute and help just to be asked to exercise more care when posting. My two cents.
participants (6)
-
Antoine Latter -
C K Kashyap -
dan portin -
David Virebayre -
Paul Sargent -
Richard Mittel