On Mon, 27 Sep 1999, Alex Ferguson wrote:
> > > > 2) Support for TRUE OO style programming.
>
> > No. I mean being able to do things such as.
> >
> > Have a collection of object of a common base class AND be able to up
> > cast them when necessary.
>
> If I understand you correctly, then the best way of doing this would be
> with existentially (boundedly) quantified data types, currently a
> non-standard extention present in hbc (and I think, ghc, these days, not
> sure if it's with the same generality.)
existentially (boundedly) quantified data types can not cast up. In order
to do that you would ALSO need to use the dramatic typing extensions found
in the GHC/Hugs library. Unfortunately the dramatic typing library leaves
a lot to be desired.
> > Be able to override methods and ALSO be able for the overriding methods
> > to call there parent methods.
>
> If by that you mean a more flexible and general means of specifying
> defaults, I'd agree. Method definitions don't have a strict 'parent'
> in the usual OO sense, since the class hierarchy isn't precisely a
> _type_ hierarchy (and a good thing too, IMO), so I'm not entirely
> confident about what you mean by parent method, though.
The point that class hierarchy isn't precisely _type_ hierarchy is
exactly the point I am trying to get gate Haskell needs to also be able to
support a class hierarchy if it is to really support OO style programming.
> > proc getLine getLine will be interpreted as the do notion above. With a
> > powerful enough type system it WILL be possible. I will go into details
> > later if anyone is interested.
>
> Please do. This is something that it would be nice to do, on one level:
> occassionally one has to 'monadise' part of one's program, and due to
> the above effect, end up driving a coach and four through the rest of
> one's code.
It has already been done to some extent in other threads.
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
