[Haskell-cafe] Re: A better syntax for qualified operators?

[John Meacham]

On Wed, Oct 18, 2006 at 04:42:00PM +0100, Simon Marlow wrote:
> The other notorious part of the Haskell grammar that isn't LL/LR(1) is 
> expressions vs. patterns.  In a statement, if you see a variable, you don't 
> know whether it is a pattern variable (apat) or an expression variable 
> (aexpr).  This is why Haskell grammars generally parse expressions and 
> patterns using the same non-terminals.

it should be noted that all of haskell (including the maximal munching
rules and lexing (but not the layout without a little preprocessing
AFAIK)) can easily be parsed by a PEG. I am going to switch jhc to using
one eventually as the maintainability advantages of a peg grammar are
persuasive (and I pull my hair out every time I have to modify the
current happy LALR parser). 

If you are writing something like a syntax highlighter for an editor,
I'd strongly recommend checking them out as a basis. they are a
straightforward generalization of regular expressions and can be made to
deal gracefully with errors simply choosing the "most plausable" choice
from ambiguous or incomplete code, something that is extremely useful
for an editor.


> >By LL(1) I'm really meaning that the grammar for interactive editing 
> >needs to be adjusted so that it is possible to maintain the invariant 
> >that as code is entered from left to right constructs and identifiers 
> >can be highlighted according to their grammatical role and highlighting 
> >(modulo incompleteness) must remain unchanged regardless of whatever is 
> >typed afterwards to the right otherwise it can become more of a 
> >liability than a help, hence my hope that some future revision of 
> >Haskell grammar might consider taking the above points into account.
> 
> So you won't be able to colour patterns differently from expressions, that 
> doesn't seem any worse than the context vs. type issue.  Indeed, I'm not 
> even sure you can colour types vs. values properly, look at this:
> 
>   data T = C [Int]
> 
> at this point, is C a constructor?  What if I continue the declaration like 
> this:
> 
>   data T = C [Int] `F`

no problem for a PEG as the infinite lookahead allows it to see the `F`
no matter how far away it is.

jhc may give horrible type errors, but by golly it's gonna give some
good parse errors. :)

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈