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 Hi Cedric, 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). Regards, Ralf ___ 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
Hi Cedric,
> > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/
>
> Good compromise between complexity, typing and usefulness.
[unfortunately also limited,
which is the reason that we came up with the monadic version:
PoorMens2.]
> 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) ?
Won't work. ;-)
Haskell standard records are not polymorphic like this.
You can't write an operation that uses a record selector without committing to
a specific record type. (With HList that underlies OOHaskell, of course, you
can!!!)
This is *precisely* the reason that:
- Gracjan's code had a get_super.
- my code has the generic .?. operator.
We could try to give up on using "normal" records.
That is, we could use a tuple convention where the first projection
returns the data part of the base class, and the second projection
returns the contribution of the derivation. However, this won't get
us anywhere. We need the nominal types introduced by the new record
types in order to represent the inheritance hierarchy in the type
system (through the Inherits or Subtype classes).
> 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 ?
Due to the abovementioned reasons, any sort of parent fields will not
interfere. Repeated inheritance simply leads to nested data composition;
that's Ok.
Ralf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hello Cédric, Sunday, June 05, 2005, 5:52:13 PM, you wrote: CP> What interested me in this was the mechanism they used to model CP> inheritance (described on page 16 & 19), based on data types instead CP> of classes. The idea being that all constructors of the Employee CP> datatype have a same parameter, 'inCommon', of type CP> 'CommonOfEmployees'. CP> The conclusion I drew from my quick & early findings is that the CP> latest method is the simplest way to get inheritance in my programs. OO approach is only one technology of "divide and conquer", just very popular in last 20 years. moreover, in OO world all the other possible programming techniques are gone to be modelled via this uniform mechanism. as a result, programmers with strong OO-only backgound tend to search solution for any programming problem in terms of classes and inheritance between them FP provides your another basic programming block - function call, or parameterized computation. quick comparision with OO basic block - class will tell you that function call is a more simple, basic element while class interface consists of several such function calls. so, simplest analogy of class interface is just tuple of functions: createCircle x y r = let draw = ... move x y = ... changeColor c = ... in (draw, move, changeColor) createRectangle x y w h = let draw = ... move x y = ... changeColor c = ... in (draw, move, changeColor) such types of interfaces cover 90% of situations where you must use classes in C++ (well, only 30%. another 60% covered by even simpler construction: data Shape = Circle x y r | Rectangle x y w h draw (Circle x y r) = ... draw (Rectangle x y w h) = ... imho, FP programming require that you think in terms "what operations i need for this object" and "what data each this operation will need" instead of OO's "what is a class hierarchy". code reusing is reached by creating general functions which receive divergent subfunctions as their parameters: calcCRC (fOPEN,fREAD,fCLOSE) = do h <- fOPEN crc <- newIORef 0 buf <- mallocBytes 65536 let go = do len <- fREAD h buf 65536 crc <- updateCRC crc buf len when (len>0) go go fCLOSE h readIORef crc calcFileCRC filename = calcCRC (hOpen filename, hGetBuf, hClose) calcCompressedDataCRC file algorithm = do calcCRC (startDecompression file algorithm, decompressBlock, finishDecompression) You can find more examples of using such technique in my program (http://freearc.narod.ru), see for example allocator/memoryAllocator, ByteStream.createFile/createBuffered/create, read_file -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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, > > http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ > > (again *not* using OOHaskell) > > From the quick skim of code: > .?. -- apply function to upcast object > .!. -- apply modification function to upcast object and substitute > returned value (new object), basically update Absolutely. > Is there any description avaliable what is PoorMens2 all about? Let me try. It's just a variation on Chris' encoding of the shape example, while trying to improve code reuse, while trying to highlight the commonalities in the data parts of the objects in the inheritance hierarchy. The approach ends up being similar to yours in so far that getters (and setters) can be made work for derived types once they are defined on the base type. I just notice that there is a short (because non-monadic) version: http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/ Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Ralf Lammel wrote: Cédric Paternotte wrote: ... > 5. With this : http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf > Gracjan Polak wrote: I've been thinking about slight generalization of this lately. Here are my semi-backed thoughts as of now. I should have mentioned http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ (again *not* using OOHaskell) From the quick skim of code: .?. -- apply function to upcast object .!. -- apply modification function to upcast object and substitute returned value (new object), basically update Is there any description avaliable what is PoorMens2 all about? A more general and preliminary observation: the entire approach is potentially more about object *composition* (and perhaps delegation) rather than inheritance. Many OO evangelists consider inheritance as a concept that was used too much in early OO times, while object composition is often more appropriate and flexible. So one *might* say that this approach does not encode a Java-inheritance solution but it does an inheritance-to-object-composition migration on the fly. So what Gracjan calls "Inherits" (and I call subtyping or substitution) is perhaps more a "delegates". Yes, I agree with this statement. The OP question was: how to simulate inheritance in Haskell? One of the answers: using delegation :) Ralf -- Gracjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] [Newbie] Quest for inheritance
There are tons of good research questions readily waiting. Such as: - What would we want to explore in OOish Haskell so that we, once more, can provide interesting input for mainstream language development? More specifically: what sorts of type inference would make a difference in Java 1.5+, C# 2.0+? - How would Haskell's type-class type system need to evolve in order to provide completely satisfying programmer experience for the uses of type classes in the various existing styles of OOish Haskell programmning? - We have Template Haskell but we are *still* rather lame when doing (OOish) language extensions. Macro systems with syntax extensions perhaps really open up a wormhole but nevertheless: *how* can we get a more experimental Haskell environment where language experiments make a good impression at the level of syntactic sugar, debugging, error messages, and all that? - How is it possible that Haskell lacks true extensible functions (modulo the kind of encoding I sent around earlier)? This is one of the big immediate benefits of OO mainstream programming. Seeing Haskell not providing them, makes me feel sad. It is also amazing that Haskell scores with complicated modes of extensibility (cf. monad transformers), but has no watertight answer when it comes to silly extensible datatypes (or classes) and functions (or methods) defined upon those. - ... Let's go to Sydney :-) (Or at the very least, let's meet at the Haskell Workshop!) Ralf > -Original Message- > From: [EMAIL PROTECTED] [mailto:haskell-cafe- > [EMAIL PROTECTED] On Behalf Of Matthew Roberts > Sent: Tuesday, June 07, 2005 12:15 AM > To: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance > > I don't think this is publishable research, there is too much other > stuff already out there. > > matt > > On 06/06/2005, at 5:58 PM, Gracjan Polak wrote: > > > Matthew Roberts wrote: > >> I have a project (for an early research student) waiting for an > >> interested student to take on. It is called "Programming patterns > >> for OO-like programming in Haskell". The basic idea is to identify > >> how to achieve OO-like organisation of your code in vanilla haskell. > >> Hopefully the student can come to a deep understanding of OO and > >> haskell programming in the process. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
I don't think this is publishable research, there is too much other
stuff already out there.
matt
On 06/06/2005, at 5:58 PM, Gracjan Polak wrote:
Matthew Roberts wrote:
I have a project (for an early research student) waiting for an
interested student to take on. It is called "Programming patterns
for OO-like programming in Haskell". The basic idea is to identify
how to achieve OO-like organisation of your code in vanilla haskell.
Hopefully the student can come to a deep understanding of OO and
haskell programming in the process.
If this could count as graduate student project and could spawn
publication then I would be interested. :)
Sounds like exactly what you need. Shame no-one has taken it up yet.
Perhaps next semester :) Anyone out there want to come to Sydney
and take it on?
As I see you did not cc the list, so currently I'm the only one that
received this message. :)
Matt
On 06/06/2005, at 3:55 AM, Gracjan Polak wrote:
Cédric Paternotte wrote:
> 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.
Me too :)
> 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.
Me too :)
> 5. With this :
http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf
>
I've been thinking about slight generalization of this lately. Here
are my semi-backed thoughts as of now.
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:
{-# 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)
main = do
let db = DB (DA 123) "zzz"
let dc = DC (DA 123)
putStrLn $ show (get_a db)
putStrLn $ show (get_a dc)
putStrLn $ show (get_b db)
putStrLn $ show (get_b dc)
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.
There are some problems left: how to update a field? or how to make
inheritance transitive. I don't know it yet :)
>
> I guess my question now is this : Are there other ways to achieve
> inheritance in Haskell ?
Me too:)
My proposal (above) is about the level of 'OO' things done in
procedural languages (example: C with GTK+ library). There must be a
better way. Any comments?
--
Gracjan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Cedric, Thanks for your investigation. Regarding your guess, the code does *not* use "state monads (for mutable data)". The whole example would make sense without IO. (So this approach is *all* different from OOHaskell :-)) The IO monad is used in Poormens2 because some of the methods might want to do side effects. For instance, in the Shape example, we want to see the progress of drawing at the Console. Also, we added an extra feature to "observe" the invocation of setters. The operators (.?.) and (.!.) can be thought of as generic getters and setters. In fact, close inspection reveals that they rather model reading and writing (or call it object observation and object mutation). Mutability is achieved in Poormens2 merely by having setters. (Optionally, if you like, you *could* use the IO monad to carry around objects. Remember, in OOHaskell, the IO monad provides IORefs for mutable objects; something not used in Poormens2.) (( Some asides: If you remove the IO monad, then the Poormens2 style is really a variation on the style hinted at in Gracjan's email. One interesting difference worth noting is that Gracjan places the actual getters in classes while Poormens2 just uses overloaded functions defined in terms of the generic operators (.!.) and (.?.). But I assert that this is a detail or a minor variation point. There could be monadic and non-monadic versions in the Subtype class; I was just too lazy at that time -- assuming that one needs monads in almost all cases anyhow. (After all, we are trying to understand the migration of imperative OO code to Haskell.) You might say that the fact whether the methods (and getters and setters, say properties) are monadic or not should not disturb the general framework, whereas it does seem to affect the design of the Subtype class used in Poormens2. In particular, you might say that the result type of a getter could be just *any* type: why then expose the monadic status in the framework's types? This is needed for the generic operator (.!.). This operator captures an *in-place* update. That is, it applies the mutator to the supertype component of the datum at hand. Since the aspect of selecting that component *and* putting back the updated component is captured generically, the operator takes a type-preserving function on the supertype and lifts it to a type-preserving function on the subtype. So type preservation is in the type of the generic mutator, and we need the monadic variation on type preservation (i.e., a -> IO a) -- if we anticipate that any mutator will have side effects (in addition to those related to the mutation of the object at hand, which is just explicit in the type!!) It is then just a consistent style to provide a similarly monadic type for generic observers. )) We call this a poor mens' approach because the coding style does not allow for a direct translation of C++/C#/Java OO code -- something we aim to provide by OOHaskell (within limits of course). Ralf > -Original Message- > From: Cédric Paternotte [mailto:[EMAIL PROTECTED] > Sent: Monday, June 06, 2005 3:36 PM > To: Ralf Lammel > Cc: haskell-cafe@haskell.org; Gracjan Polak > Subject: 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
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
RE: [Haskell-cafe] [Newbie] Quest for inheritance
> Cédric Paternotte wrote: > ... > > > 5. With this : > http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf > > > > Gracjan Polak wrote: > > I've been thinking about slight generalization of this lately. Here are > my semi-backed thoughts as of now. I should have mentioned http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/ (again *not* using OOHaskell) The actual example encodes Chris Rathman's shape benchmark. The underlying story is somewhat similar to Gracjan's email. Compared to the code that Gracjan posted, - this code pinpoints another issue of this poormens' approach: get_super is quite obviously not enough if you end up wanting mutable objects. You need a setter as well. (My feeling here is that the encapsulation could be better. It would need coding effort to avoid that all data is public.) - this code also shows how the "fake inheritance through data composition" approach blends with virtual methods: one uses an extra class per abstract/virtual method. (Clearly, one can potentially try to bundle some methods in a class.) An issue here is that client code might get bloated with constraints: for datatype subtyping *and* all used virtual methods. Alternatively, one can place the OO methods (their functional counterparts) in the data capsules themselves! Then you get into the trouble of self references. A more general and preliminary observation: the entire approach is potentially more about object *composition* (and perhaps delegation) rather than inheritance. Many OO evangelists consider inheritance as a concept that was used too much in early OO times, while object composition is often more appropriate and flexible. So one *might* say that this approach does not encode a Java-inheritance solution but it does an inheritance-to-object-composition migration on the fly. So what Gracjan calls "Inherits" (and I call subtyping or substitution) is perhaps more a "delegates". Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
--- Cédric Paternotte <[EMAIL PROTECTED] > 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 ? The Haskell shapes example was a recreational activity that started with Jim Weirich's challenge at: http://onestepback.org/articles/poly/ As Jim notes, inheritance was not the point of the exercise. And the Haskell example I did was somewhere in the middle of 56 other languages I had been tinkering with: http://www.angelfire.com/tx4/cus/shapes/index.html In most of the OOP languages, we tried to use code inheritance if it was available, but where it was not obvious or easily achievable (Erlang, Mercury, Clean, Haskell), it was bypassed. I did spend a bit of time trying to figure out how to get subtype polymorphism to work in Haskell, but in terms of my familiarity with the language, I am by no means proficient with the language. Best to ask Ralf about the more involed stuff. :-) > 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 ;) Subtypes may share some common behavior but from a top level perspective, a Rectangle type is not the same as a Circle type. Existential types allow you to treat the different types via the common behavior defined in the parent type. Without existential types, you can have only monomorphic collections. Chris Rathman ___ 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
The differences in the two shape examples doesn't have to do with code inheritance - it has to do with subtype polymorphism. 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. Generally speaking, OO programming is based on three properties (a) encapsulation; (b) inheritance; and (c) polymorphism. Well, Haskell has pretty good means of encapsulation (though I'm spoiled by ML at the moment). And existential types can get you subtype polymorphism. 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. A language like Sather actually treats type inheritance and code inheritance as seperate things. Languages that mix the two concepts have their own set of difficulties, as the two forms of inheritance are sometimes at odds with each other. Anyhow, the classic case for code inheritance is from a re-use perspective - i.e. not having to repeat the code in multiple places. The classic problem with code inheritance is that it breaks encapsulation, as classes that reuse code from a superclass become tightly coupled with the implementation. 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. From a Java perspective, you usually have to decide whether you want single inheritance via class extension, or multiple inheritance via interface implementation. >From the perspective of Java, the shape example that does not have code inheritance corresponds to the Java world of Interfaces - with Interfaces not allowing code inheritance. Chris Rathman --- Cédric Paternotte <[EMAIL PROTECTED] wrote: > 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 ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Cédric Paternotte wrote: Hi Gracjan, 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. Yes. I think this is the whole point of inheritance :) 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 ? This is exactly what I described as "private inheritance". If you have (Inherits DA DB) and (Inherits DB DC) this does not mean that you have automatically (Inherits DA DC). Why? This would require instance: instance (Inherits a b,Inherits b c) => (Inherits a c) where ... but this summons known problem: multiple inheritance. How to chose b? Imagine such situation: data DA; data DB; data DC; data DD instance Inherits DA DB where ... instance Inherits DA DC where ... instance Inherits DB DD where ... instance Inherits DC DD where ... DD inherits DA *twice*. So b in above instance declaration would not be determined uniquely. 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. I agree with typing, but compared to Java this is actually not limited but more powerful, because it gives greater control over inheritance. Most important aspect to me is that inheritance can be specified *after* data declaration. Imagine you have some strange library that has DA and DB, that are obviosly in generalization-specialization hierarchy, but some jerk forgot to inherit one from another. In Java you are toast, in Haskell you can specify inheritance relation in your code :) 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 ;) 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. Cédric -- Gracjan ___ 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 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
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) 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" 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? (( 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. Ralf > -Original Message- > From: [EMAIL PROTECTED] [mailto:haskell-cafe- > [EMAIL PROTECTED] On Behalf Of Cédric Paternotte > Sent: Sunday, June 05, 2005 6:52 AM > To: haskell-cafe@haskell.org > Subject: [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/) > > Whi
Re: [Haskell-cafe] [Newbie] Quest for inheritance
Cédric Paternotte wrote:
> 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.
Me too :)
> 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.
Me too :)
> 5. With this :
http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf
>
I've been thinking about slight generalization of this lately. Here are
my semi-backed thoughts as of now.
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:
{-# 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)
main = do
let db = DB (DA 123) "zzz"
let dc = DC (DA 123)
putStrLn $ show (get_a db)
putStrLn $ show (get_a dc)
putStrLn $ show (get_b db)
putStrLn $ show (get_b dc)
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.
There are some problems left: how to update a field? or how to make
inheritance transitive. I don't know it yet :)
>
> I guess my question now is this : Are there other ways to achieve
> inheritance in Haskell ?
Me too:)
My proposal (above) is about the level of 'OO' things done in procedural
languages (example: C with GTK+ library). There must be a better way.
Any comments?
--
Gracjan
___
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
