> Consider the following Haskell 98 expressions:
>
> (let x = 10 in x `div`)
> (let x = 10 in x `div` 3)
>
> To parse the first, a bottom-up parser should reduce the
> let-expression
> before the operator, while to parse the second it should shift.
> But it needs 4 tokens of lookahead to decide which to do. That seems
> unreasonable, and is well beyond the LALR(1) parsers used by
> Hugs and GHC.
> Replacing `div` by + needs 2 tokens of lookahead, which is
> still too much.
> I think the first should be made illegal, but can't think of
> a clean rule.
> (There are similar expressions using lambda and if.)
This is a known problem with the Haskell grammar. Another example in a similar vein is
let x = 3 in x == 4 == True
which should parse as
(let x = 3 in x == 4) == True
according to the "extends as far to the right as possible" rule, because '==' is
nonfix. In order to do this, the parser must have access to the fixity information
for '==', which is unreasonable (fixity declarations can even be local to a binding
group). Perhaps it is possible to post-process the parse when the fixities have been
resolved, but that seems overly complex even if it is possible.
My favourite solution would be to remove the notion of operator precedence from the
grammar altogether and specify fixity resolution separately.
Cheers,
Simon
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
