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
'a'.
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!!! ;-)
Brian.
--
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.
http://www.metamilk.com