Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Ralf, See Section 7.3 of the latest revision of Haskell's overlooked object system. There are pointers and explanations. This discussion also clarifies that the phantom approach is tailored for foreign library and component import (but it can be generalized and has been indeed, by Burton in a paper from 1990). Thank you for bringing us this rewrite. It is definitely worth it in my opinion. Read it once and although I need a few more reads to digest it, I could get a much better sense of what was going on. I also found it both easier to graps and more comprehensive. Thanks for this quality paper. I noticed it's still in draft stage so I conclude there'll be further revisions... Cédric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
On 6/6/05, Gracjan Polak [EMAIL PROTECTED] wrote: If you stick to single inheritance there is other way to simulate OO in Haskell. Look for phantom types. Whole wxHaskell (for example) is based on this concept. I heard about them indeed but barely found clear explanations of it. Any useful pointer you're aware of maybe ? Cédric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
I just notice that there is a short (because non-monadic) version:
http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/
I have to say that this version of the Shape example is my favourite so far.
Good compromise between complexity, typing and usefulness.
May I just suggest an improvement that could further improve the code re-use ?
I noticed that both Rectangle and Circle need to redefine the
operators because of the different names of their respective delegate
to Shape, namely rectangle2shape and circle2shape.
I we were to give these fields the same name ('parent', or 'super') in
both Rectangle and Circle, could it be that we can avoid to redefine
the operators by moving their definition upwards (and thus requiring
only one definition for both classes) ?
I guess that would also mean that we restrict ourselves to
single-inheritance since we rely on the uniqueness of the name
'parent' throughout. But since single inheritance is IMO enough to fit
most needs I don't see it as a problem.
Would it then be a problem if we further subclass Rectangle in, say,
two subclasses Square and NonSquareRectangle ? Would that still work
or would there be a collision between the multiple 'parent' fields ?
Cédric
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Gracjan,
On 6/5/05, Gracjan Polak [EMAIL PROTECTED] wrote:
First of all, in Haskell there will be strict separation between
interfaces and data, so almost every method will be declared twice. This
is not so strange to anybody programing in Java, but for C++ programmers
can be. Inheritance relation is specified after data. There is also
separation between two concepts: what interfaces each piece of data
implements and which intefaces given interface inherits. So:
I don't mind declaring functions headers more than once as long as I
don't have to do it with their body.
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
module Main where
-- general inheritance relation
class Inherits b x where
get_super :: x - b
-- declare interface with one method
class IA a where
get_a :: a - Int
-- define data with one field
data DA = DA { da_field :: Int }
-- say how data DA conforms to interface IA
instance IA DA where
get_a x = da_field x
-- declare some other interface IB
-- note: IB is unrelated to IA
class IB a where
get_b :: a - String
-- data that inherits fields of DA and adds one another field
data DB = DB { db_super :: DA, db_field :: String }
-- DB inherits fields and methods of DA
instance Inherits DA DB where
get_super x = db_super x
-- data DB implements interface IB
instance IB DB where
get_b x = db_field x
-- some other random data
data DC = DC { dc_super :: DA }
-- DC implements interface IB
instance IB DC where
get_b x = show (get_a x)
-- and inherits DA
instance Inherits DA DC where
get_super x = dc_super x
-- now the tricky part: state that every data x inheriting DA
-- implements all interfaces of DA (repeat for each interface)
instance (Inherits DA x) = IA x where
get_a w = da_field (get_super w)
This is smart. So I understand the point of this part is to forward
the function call to the parent (through get_super). All you have to
do is to define these forwards in each inheriting data.
Does it also mean that, in each inheriting data, you have to define
these forwards to all your parents (meaning not only to the one just
above, but all of them) ? In other words if I was to define a data DD
which inherits from DB (and thus also from DA), will I have to define
forwards for both get_a and get_b ? If not, how would you declare it ?
As you see there is much more writting as in Java. But this gives better
control over inheritance and subsumption because everything must be
stated explicitly. Multiple inheritance is allowed :) Also it is
private inheritance (as in C++) by default.
I think I like this way of dealing with inheritance. There's a bit
more typing indeed and it's kind of limited but it has the advantage
of being relativily simple to put in action.
What I really like with this is that you can come up with new data
types inheriting DA without having to change anything in the
declaration of DA.
I guess you'd just better avoid having too many levels of hierarchy as
it tends to get more and more verbose ;)
Cédric
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Ralf, On 6/6/05, Ralf Lammel [EMAIL PROTECTED] wrote: Re: your enumeration. Let me add one more bullet. In cases where inheritance is about abstract base classes and concrete subclasses ((add interface polymorphism likewise)) you can use a (for unknown reasons) unappreciated pattern for extensible datatypes in Haskell: http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs (Note: conceptually unrelated to OOHaskell) Okay. I wasn't looking for that kind of inheritance but thanks for bringing it in. Re: OOHaskell Thanks for calling this a very good and thorough attempt :-) I would really like to understand why you think that a) this could possibly be a huge hack Well, please don't pay attention to my wording ;) It's only my beginner's narrow view of a paper targeted at more advanced users. That's why I added the last sentence in my initial post. I regard your work as the most comprehensive I've seen on the topic. b) awkward syntax would be involved. Regarding a), could it be that you are overwhelmed by the details of the implementation of OOHaskell' *typeful* object system? Wouldn't you be similarly concerned when looking at details of *any* other object system of *any* other *typed* language? I certainly am. (( We are currently massaging the OOHaskell paper. From what you say, it might seem appropriate to emphasize the OO programming API more clearly, while moving implementation details of OOHaskell out of the face of a programmer who migrates from C#/Java to Haskell. )) Regarding b), could it be that you would want to see special keywords in your face, rather than thinking in terms of records, monadic functions, open fixpoints, closing fixpoints, ...? If yes, I guess that's an valid desire. If there was a mainstream technique for Haskell syntax extension, we want to use it for OOHaskell. Yes I do, as most of us would I believe. I remember you talking in the paper about adding syntactic sugar to OOHaskell to make it more convenient. That would certainly ease the path for Haskell starters. But, from what you're saying, I understand you must be hitting a wall somewhere. I don't say sugar is essential but it helps. You know I just don't feel comfortable using concepts I don't fully understand and OOHaskell relies on many advanced ones. The standard do notation is such a nice example of syntactic sugar, it allows you to use monads without even knowing it. The point here is that when you use the do notation, you don't have the feeling you're using something you don't fully master. But I'm not gonna lecture you on this ;) Regarding your paper, all I can say is that I'm not against a version targeted at more entry-level users ! This sounds like a very good idea. Otherwise, I'll certainly go back to your work, but once I got the necessary knowledge to tackle it. In the meantime I'll be keeping an eye on the project for incoming events. Slightly off-topic, but I'm sure there are many people out there, coming from the same background as mine, who have a hard time getting into Haskell just because there's no Haskell for Java/C++/OO programmer. The ice on the cake being the Haskell way of naming its structures, that is so misleading for a Java programmer. If you knew how long it took me only to figure that Haskell names its interfaces classes and its classes instances, you wouldn't believe me. Cédric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Chris, On 6 Jun 2005 14:53:11 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The differences in the two shape examples doesn't have to do with code inheritance - it has to do with subtype polymorphism. Does this mean that I was wrong in saying in my initial post that existential types can be used to get code inheritance ? Or is it just that the Shapes example has never been meant to illustrate that side of things ? Existential types allow you to throw different subtypes into a collection and have the function dispatch on the common superclass type. The example without existential types demonstrates parametric polymorphism, but not subclass polymorphism. Okay, I think I've finally spotted the difference : Using existential types you actually managed to put both CircleInstance and RectangleInstance in the same list. I didn't notice that detail at first. All the difference lies in that line ;) So I understand this is something you obviously cannot do when using classic subtyping. Incredible. This is weird, I mean that's the kind of feature I would take for granted. That makes existential types much more useful indeed. Even essential I would say. As far as inheritance, there's actually two kinds that occur in most OO languages. The first being type inheritance (which really just gets you subtype polymorphism). And then there's code inheritance - which is what you are trying to achieve. Thanks for the clarification. At any rate, I consider inheritance to be a convenience mechanism, and not vitally necessary to the concepts of encapsulation, type inheritance, and polymorphism, though I realize that many do consider it important. Well, on the -way too big for my head- projects I'm working on, inheritance saves my life many times a day. Chris Rathman Thanks for a lot for your time Chris, think I'm slowly starting to get the picture of all this. Cédric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Ralf, I should have mentioned http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ (again *not* using OOHaskell) It's been an interesting evening. I've been having a go at your poormen's source code and, although it's different from OOHaskell, I still find it very similar in the sense that it's using the same concepts, namely infix operators (for syntactic sugar I assume) and state monads (for mutable data). But I had a look at it anyway ;) From what I gathered today infix operators are just like ordinary functions, that differ only in the way you pass them parameters. I understand the .?. and .!. operators in your code are shortcuts that apply a function to the parent type, respectively for get and set operations. The only thing I couldn't figure is the reason of using monads. I noticed they (returnIO) were extensively used in the setters and in the .!. operator. Do monads provide features without which this whole thing wouldn't be possible ? What is it exactly they provide in this context ? A more general and preliminary observation: the entire approach is potentially more about object *composition* (and perhaps delegation) rather than inheritance. That's also the way I see it. Cédric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Quest for inheritance
Hi Andre, Manuel Chakravarty and I also wrote a paper titled Interfacing Haskell to Object-Oriented Languages that you might find useful: I've been reading it and from what I understood the technique you've come up with is used to model foreign OO language hierarchies so that Haskell can interface with them. My question is can you use it to code in Haskell in a OO way or is it just meant to provide bridges to these foreign OO objects ? I noticed most examples in the paper were related to the matters of interfacing. Or is it more than that ? Could you, for instance, craft a version of, say, the Shapes example with this approach ? Thanks, Cédric Paternotte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Newbie] Quest for inheritance
Hi. This is my first message here so Hello to everyone. I'm just starting to learn Haskell and I really think it's a cool language. Coming from an OO world, I've been looking for ways to achieve inheritance as you get it in Java and the likes. I know OO and inheritance is not really the point of Haskell and that other mechanisms are provided to somewhat achieve reuse. But it's a way of programming I've been so used to that I feel lost without it. You might think I'm heading in the wrong direction. My mistake I have to agree. Let's take it as a learning exercise then. So I've been searching the net for *easy* ways to get it and the least I can say is that I'm confused. It soon became apparent that, inheritance not being a core feature of the language, many people have been hacking Haskell to come up with similar effects (btw I never thought there could be so many ways to reach the same goal...Haskell programmers are clever bastards). Of the many implementations that I've found, few are really simple and most achieve it with various levels of success and/or dodgy syntax. Here are the various techniques I've come across so far : (I'm far from understanding them all) 1. Through existential types As shown in the Shapes example at http://www.angelfire.com/tx4/cus/shapes/haskell.html. However, I couldn't spot the advantage over the standard version using normal classes at http://www.angelfire.com/tx4/cus/shapes/haskell98.html The getX function still needs to be defined in both RectangleInstance and CircleInstance. This is not what I call inheritance. Inheritance would make it possible to define getX only once in ShapeInstance. Or maybe the point was only to demonstrate polymorphism. But then what is the advantage of using existential types ? It just looks like more work compared to the standard version that also makes use of polymorphism. Or am I missing something ? 2. Through typeful heterogeneous collections This technique is described at http://homepages.cwi.nl/~ralf/OOHaskell/ and is able to bring most OO principles into Haskell. This seems to be a very good and thorough attempt. Unfortunately it looks more like a huge hack than a solution. The problem I have with it is the awkward syntax it requires, which to my newbie eyes doesn't look like Haskell anymore. 3. Through phantom types I couldn't find any idiot-proof documentation on this topic but this technique seems to be used to model inheritance. The few papers I've come across (http://research.microsoft.com/Users/simonpj/Papers/oo-haskell/overloading_conf.pdf , http://www.informatik.uni-bonn.de/~ralf/publications/Phantom.pdf ,http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf ) seem very interesting but all go way over my head. 4. Through O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/) Which is a non standard extension of Haskell that seems to be dead anyway. 5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf This is a very interesting paper, at least for a newbie like me who's used to Java. The aim of this paper was to develop a same application in both Java and Haskell and to compare the resulting implementations afterwards. What interested me in this was the mechanism they used to model inheritance (described on page 16 19), based on data types instead of classes. The idea being that all constructors of the Employee datatype have a same parameter, 'inCommon', of type 'CommonOfEmployees'. The data type CommonOfEmployees consists of all the fields shared by all types of employees. By then defining polymorphic functions that only use the 'inCommon' property of any employee, they've managed to instantiate these methods only once. My explanation must be horrible to you but you'll certainly get it by reading their paper. The Haskell source code can be found here :http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/Haskell_Impl/ The conclusion I drew from my quick early findings is that the latest method is the simplest way to get inheritance in my programs. I guess my question now is this : Are there other ways to achieve inheritance in Haskell ? Simpler techniques ? Or more accurate / comprehensive ? Would you have pointers to useful resources ? I apology in advance for the errors, false assertions, misconceptions, confusions made in this document. I'm still learning Haskell. I'd just like to get the most of it. Cedric Paternotte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
