[Haskell-cafe] Re: Editors for Haskell

[Doaitse Swierstra]

One might want to take a look at:

http://www.cs.uu.nl/research/projects/proxima/

where we have built (a.o.) an editing environment for Helium programs  
(a subset of Haskell),

      Doaitse


On 2006 jun 02, at 10:57, Brian Hulley wrote:

> Simon Marlow wrote:
>> Malcolm Wallace wrote:
>>> "Brian Hulley" <brianh at metamilk.com> wrote:
>>>
>>>
>>>> Thanks for pointing this out. Although there is still a problem  
>>>> with
>>>> the  fact that var, qvar, qcon etc is in the context free syntax
>>>> instead of the  lexical syntax so you could write:
>>>>
>>>>        2 `    plus      ` 4
>>>>        (    Prelude.+
>>>>               {- a comment -} ) 5 6
>>>
>>>
>>> You appear to be right.  However, I don't think I have ever seen a
>>> piece of code that actually used the first form.  People seem to
>>> naturally place the backticks right next to the variable name.  
>>> Should we consider the fact that whitespace and comments are
>>> permitted between backticks to be a bug in the Report?  It certainly
>>> feels like it should be a lexical issue.
>>
>> I tend in the other direction: I'd rather see as much as possible
>> pushed into the context-free syntax.  The only reason that qualified
>> identifiers are in the lexical syntax currently is because of the
>> clash with the '.' operator.
>>
>> I'm not sure I can concisely explain why I think it is better to use
>> the context-free syntax than the lexical syntax, but I'll try.  I
>> believe the lexical syntax should adhere, as far as possible, to the
>> following rule:
>>   juxtaposition of lexemes of different classes should not affect
>>   the lexical interpretation.
>>
>> in other words, whitespace between different lexemes is irrelevant.
>
> A question here is: what is a lexeme?
>
> For example there are floating point numbers, which are written  
> without spaces, but which could be considered to consist of  
> primitive whole-number lexemes interspersed with . e -
>
>    34.678e-98
>
> I don't see what the difference is between them and
>
>    Prelude.+
>
> especially since we *really* need the dot for other purposes in the  
> CFG such as composition and (hopefully at some point) field selection.
>
> Since Prelude.+ is by the above argument a single lexeme, it seems  
> consistent to say that
>
>    `Mod.Id`
>    (Mod.+)
>
> are also single lexemes. The brackets in (Mod.+) have a lexical  
> purpose, to turn a symbol into an id, which is very different imho  
> from the use of brackets to parenthesise expressions or form sections.
>
> For example, should a parser consider ( +   ) to be an incomplete  
> parenthesised expression with 2 gaps or an id formed from the  
> symbol + ? At the moment of course it would be an id but this  
> causes problems when you're trying to parse Haskell and highlight  
> incomplete expressions, because you'd expect that if the user  
> indended to just make an id there wouldn't be any reason to leave  
> spaces between the symbol and the brackets.
>
> In many ways it would be a lot easier if the (lexical) grammar was  
> changed so that the "turning a symbol into an id" would just be  
> indicated by parentheses round the (unqualified part of the) symbol  
> alone not the whole thing thus:
>
>     Prelude.(+)
>
> so that the first lexical rule would be
>
>     1) Parentheses around an unqualifed symbol turns it into an id
>
> Then the ` could be used to turn a (possibly qualified) id into a  
> symbol:
>
>    `Prelude.plus
>    `Prelude.(+)
>
> and there would be no need for a closing `, so the second rule  
> would be:
>
>     2) A grave before an id turns it into a symbol (that can't  
> subsequently be turned back into an id!)
>
> There are at least five motivations for suggesting the above changes:
>
>     1) It allows operator expressions to be parsed by LL1 recursive  
> descent :-)
>     2) The low level details of whether or not a symbol or id is  
> used is kept to the lexical level
>     3) You can use a qualified function and an operator without  
> knowing in advance whether it has been declared as a symbol or an  
> id in the module. For example, you could type
>                  x `Mod.
> and expect to get a pop-up list of functions in Mod, such as (+)  
> add etc, whereas with the current rules, you'd have to go back and  
> add graves around the qualified function if the function was  
> declared as an id and remove the grave if it was already declared  
> as an operator.
>      4) Only one grave is needed :-)
>      5) An editor can give more feedback, by distinguishing between  
> incomplete expressions and the turning of symbols into ids
>
> 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