4 Jun 2006 21:27
Re: Re: Editors for Haskell
Doaitse Swierstra <doaitse <at> cs.uu.nl>
2006-06-04 19:27:24 GMT
2006-06-04 19:27:24 GMT
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
RSS Feed