On 8/23/06, Brian Hulley
Hi - Disregarding my last proposal which involved the use of {} in types, I am wondering if anyone would agree with me that it would be a good idea to use {} instead of () when writing out the context ie:
foo :: (Num a, Bar a) => a -> a
would become:
foo :: {Num a, Bar a} => a -> a
and the same for every other situation in the language where a context appears.
My reasons are twofold:
1) The context is supposed to be understood (afaiu) as a *set* of constraints not a *tuple* of constraints (ie what relevance does the ordering implied by the tuple notation have here?), so the using of set braces seems mathematically more appropriate
I just started programming in Haskell again recently and I cannot even think of a case where any kind of brackets should be necessary. In the report [1], it clearly shows that a context is always followed by "=>." Are the parantheses just used to reduce lookahead requirements for parsers? If so, perhaps the parentheses should be made optional to make them easier to read for people. Plus, then there would not be any tuple vs. set confusion. BTW, at least GHC allows duplicates in the context, like [ foo :: (Num a, Num a) => a -> a ], so I don't know if calling it a "set" is really appropriate either. 2) It would allow an editor to give the correct fontification for an
incomplete type expression. At the moment, if you'd just typed:
foo :: (Bar
the editor would have no way of knowing if "Bar" is a classcon or a tycon, whereas with:
foo :: {Bar
the opening brace immediately informs the editor that the following text should be parsed as a context and so it could fontify Bar appropriately.
What about [ foo :: Bar ] when typing [ foo :: Bar a => a -> a ]? It would be a mistake to require the grouping symbols even when there is only one element in the context. I think that the editor has to be know enough about the program to distinguish classes and type constructors without any grouping symbol requirement. - Brian