[Haskell] PROPOSAL: class aliases

Jan-Willem Maessen jmaessen at alum.mit.edu
Thu Oct 13 10:18:24 EDT 2005


On Oct 12, 2005, at 8:00 PM, John Meacham wrote:


> [longish proposal for class aliases]
>

Very nicely done, by the way.


> == Notes ==
>
> * class aliases are also able to introduce new superclass  
> constraints, such as
>   in the Num example we also want to enforce a (Eq a, Show a)  
> superclass
>   constraint. the interpretation is straightforward, Num in type  
> signatures
>   expands as if those were part of the alias and when declaring  
> instances the
>   existence of instances for the superclasses are checked, but not  
> filled in
>   automatically. I didn't show an example so as to not confuse the  
> basic idea
>   and because I have not come up with a syntax I am happy with.  
> (suggestions
>   welcome)
>

It sounds like there may be a simpler initial extension lurking under  
this, see below.


> ...
> * I had an earlier supertyping proposal you might know about, I  
> feel this is
>   a much better proposal even though it doesn't fully subsume my  
> supertyping
>   proposal, I feel it solves the problems it was meant to solve in  
> a cleaner
>   and easier to implement way.
>

Having read the previous proposal, I'm inclined to agree.  I feel  
like I can explain this one in a couple of minutes, and the listener  
will be able to figure out most of the subtleties without additional  
help.


> * You may wonder why for the num example I put Additive a in the  
> class alias
>   even though it was already a superclass of AdditiveNegation. that is
>   because class aliases do not change the meaning of superclasses,  
> you need
>   to explicitly list a class if you want instance declarations to  
> propagate
>   methods to it. superclasses are checked just like normal in class  
> aliases.
>

This is the one possible exception to that.  Again, see below.


> * incidental but not earth-shattering benefits include being able to
>   declare an instance for a class and all its superclasses at once,
>   smarter defaults when you are combining related classes, and much
>   nicer type signatures by being able to create your own aliases for
>   common combinations of classes.
>

It seems to me this is a simpler extension here which might serve at  
least as a conceptual stepping-stone to full class aliases---the  
ability to declare an instance for a class and all its superclasses  
at once.  Given that ability, class aliases actually look like a  
relatively simple extension.

One final thing which would be nice is the ability to define  
instances of superclass methods in a subclass declaration.  But this  
takes things in a different direction entirely.

-Jan-Willem Maessen


>
> -- 
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>




More information about the Haskell mailing list