"class []" proposal Re: [Haskell-cafe] One thought: Num to 0as ? to list?

Brian Hulley brianh at metamilk.com
Tue Aug 22 13:35:21 EDT 2006

Brandon Moore wrote:
> Perhaps there is something similar that could be done with type
> classes. In particular, I very much like Daan's rule of only inlining
> a constraint if the type it binds is only used once, which would mean
> Num -> Num -> Num
> would be equivalent to
> (Num a, Num b, Num c) => a -> b -> c

A problem here is that you need to know that Num is a class and not a tycon 
before you can work out what the above syntax means. For an editor, suppose 
you open a new file and enter:

    module M
    import Q

    foo :: Z -> Z

how is the editor supposed to fontify Z if module Q has not yet been 
written? With the existing syntax, just the grammar alone is enough to 
determine that Z is a tycon.

> For an alternate proposal, how about allowing a single-parameter type
> class as an annotation around a subexpression of a type expression,
> meaning the same as a constraint that that subexpression belong to
> that class. For example,
> (+) :: Num a -> a -> a,
> or
> sort :: [Ord a] -> [a]
> this is a bit closer to how I would read the types,
> "sort takes a list of comparable a to a list of a"

To me this looks as if you mean (assuming Ord is known to be a class):

    sort :: forall a. [ forall a. Ord a=>a] -> [a]

because the Ord is hidden inside the list brackets. In contrast:

    sort :: forall a. Ord a => [a] -> [a]

makes it very clear that the Ord constraint scopes over both occurrences of 

I feel "if it ain't broken don't fix it", and not only is the existing 
syntax not broken, it's already (imho) absolutely perfect in it's clarity 
and consistency ie adding all these dubious "shortcuts" to the Haskell type 
syntax would be about as sensible as deliberately chopping one's legs off to 
walk quicker!!! ;-)

Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.


More information about the Haskell-Cafe mailing list