John Meacham <[EMAIL PROTECTED]> writes:
> = Class Aliases =
>
> This is a proposal for a language extension which will hopefully mitigate
> the issues holding back evolution of the standard prelude as well as provide
> useful class abstraction capabilities in general.
I like your proposal a lot. Do you have an implementation of it in jhc?
> > class Foo a where
> > foo :: a -> Bool
> > foo x = False
> >
> > class Bar b where
> > bar :: Int -> b -> [b]
>
> > class alias (Foo a, Bar a) => FooBar a where
> > foo = ...
> > bar = ...
One thought: how will class aliases interact with type inference?
e.g. if a declaration contains only a call to 'foo', should we infer
the constraint Foo a, or FooBar a? Can there ever be a situation where
choosing the more specific dictionary could leave us without a 'bar'
method at some later point in the computation? (cf. up-casting and
down-casting in OO languages).
If I declare a function
baz :: Bar a => ...
and then pass it a value which actually has a FooBar dictionary rather
than just a Bar, will the implementation be able to find the right
offset in the dictionary for the 'bar' method? How? (I know jhc
eliminates dictionaries at compile-time, but other implementations
do not.)
Regards,
Malcolm
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
