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