Kevin Atkinson:
> Yes but often putting things in type classes is tedious to do. I also
> want to be able to overload not only on the TYPE of parameters but also
> on the NUMBER of parameters. It IS possible to do these things and it
> DOES make sense in a curing system.
That's far from clear. Certainly, I don't think it's likely to be
reasonably possible a conversative extension.
> > > 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.)
> 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.
> > > 4) Being able to write
> > > do a <- getLine
> > > b <- getLine
> > > proc a b
> > > as
> > > proc getLine getLine
> > > and the like.
> 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.
But it's a somewhat subtle subtle to address without either a) severely
breaking the type system; and b) totally confusing the user, if the
result involves quite different entities being denoted by the same
symbol. The question is, if one is using the same symbol for a
collection of semantics objects, then sensibly, they must be _related_
things, so, how best to capture that relatedness? The OOP answer
of 'not at all' is a very poor one, IMO.
Cheers,
Alex.
