[Haskell-cafe] Proposal to allow {} instead of () in contexts

[Brian Hulley]

On August 23, 2006 5:16 PM, Brian Smith  wrote
> On 8/23/06, Brian Hulley <brianh at metamilk.com> wrote:
>> 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
>>
>> 1) The context is supposed to be understood (afaiu) as a *set*

> 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.

Also, parens should not be needed in

    data D = D | E deriving Eq, Ord

because a data decl can never be confused with a tuple component. It would 
certainly be very much neater to not have to use parens just because there 
is more than one constraint / deriving class.

Certainly the current need for parens in these situations seems like a wart 
and always trips me up.

> 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.

I'd argue that this is precisely what makes the above a set rather than a 
tuple: {Num a, Num a} === {Num a}
Also, I'd argue that an error should be given when a constraint is 
duplicated because it has no meaning thus probably indicates some 
misunderstanding on the part of the programmer (unless the idea is to pave 
the way for class aliases where one may want to write code that can compile 
under different alias environments).

>> 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.

If braces were used even in the case where there was only one constraint the 
=> would never be needed as in:

    foo :: {Bar a} a->a

so there would be no more characters to type yet the notation would have the 
advantage that the signature could be understood by itself without requiring 
the user to have already defined Bar somewhere.

I was also thinking that in:

    foo :: {Ba

Ba could be fontified as a classcon to help the user realise that he/she is 
typing a classcon at that point. However it also could be helpful to only 
fontify known tycons/classcons and have a different font for "unknown 
entity", and in practice I suppose it is likely that you'd only start 
entering signatures etc when the types and classes have already been 
defined.

BTW this also assumes tycons and classcons share the same namespace. If this 
were changed in future, then it would no longer be able to determine the 
type/class distinction just by the id (but of course would eventually be 
known after the => but this is too late for providing syntax help while 
editing the context itself).

Thanks for the idea of making parens optional. I intend to try this as the 
editor could still save/load files in normal H98 syntax (with parens) yet 
allow them to be displayed/edited without for added user convenience... :-)

Regards, 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe