H98 Report: expression syntax glitch
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.)
(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.
nhc98 manages to parse and compile both expressions with ease, no doubt because it uses parser combinators rather than a table-driven mechanism. Regards, Malcolm
On Mon, Feb 25, 2002 at 03:38:39PM +0000, Malcolm Wallace wrote:
nhc98 manages to parse and compile both expressions with ease, no doubt because it uses parser combinators rather than a table-driven mechanism.
Yes, but it reports type errors for the variants f x = (\x -> x*x .) g x = (if x then 1 else 2 +) and it accepts h = (let op x y = y in 3 `op`) so I suspect it's misparsing these as f x = (\x -> (x*x .)) g x = (if x then 1 else (2 +)) h = (let op x y = y in (3 `op`)) and in the earlier example it didn't make any difference.
Yes, but it reports type errors for the variants f x = (\x -> x*x .) g x = (if x then 1 else 2 +) and it accepts h = (let op x y = y in 3 `op`) so I suspect it's misparsing these as f x = (\x -> (x*x .)) g x = (if x then 1 else (2 +)) h = (let op x y = y in (3 `op`))
But I would claim that nhc98 is parsing these correctly, at least according to section 3 of the Report. " The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the meta-rule that each of these constructs extends as far to the right as possible. As a consequence, each of these constructs has two precedences, one to its left, which is the precedence used in the grammar; and one to its right, which is obtained via the meta-rule. " In the table of precedence in the original Report (now deleted in the revised Report), it makes it clear that a rightward-extending let, if, or lambda has a lower precedence than an infix operator, so for instance the parse h = (let op x y = y in (3 `op`)) is correct and h = ((let op x y = y in 3) `op`) is not. Regards, Malcolm
On Mon, Feb 25, 2002 at 04:30:24PM +0000, Malcolm Wallace wrote:
Yes, but it reports type errors for the variants f x = (\x -> x*x .) g x = (if x then 1 else 2 +) and it accepts h = (let op x y = y in 3 `op`) so I suspect it's misparsing these as f x = (\x -> (x*x .)) g x = (if x then 1 else (2 +)) h = (let op x y = y in (3 `op`))
But I would claim that nhc98 is parsing these correctly, at least
But, for example, "x*x ." is not a valid left section - parentheses are required. Ian
participants (3)
-
Ian Lynagh -
Malcolm Wallace -
Ross Paterson