RE: Language.Haskell.Parser and layout rules
On 18 February 2005 16:31, Mirko Rahn wrote:
The Report (section 9.3, especially notes 1 and 2) says "A nested context must be further indented than the enclosing context", ...
Okay, I understand, but the behavoir of hugs vs ghc vs Language.Haskell.Parser is still strange: The sniplets
** A: g xs = do ys <- workM xs if null ys then return [] else do zs <- workM ys return zs
** B: g xs = do ys <- workM xs if null ys then return [] else do zs <- workM ys return zs
** C: f xs = case xs of y:ys -> case ys of z:zs -> zs
** D: f x = case x of False -> do { return x; }
are accepted by A B C D ghc yes no no yes hugs yes no no no Language.Haskell.Parser.parseModule no yes yes no report no no no no
Hugs is probably the most correct here. A is intentionally parsed by Hugs and GHC. D is a known bug in GHC. It looks like Language.Haskell.Parser may have bugs in this area. Interestingly, Haddock is better than GHC, giving the same results as Hugs. Haddock's parser is based on Language.Haskell.Parser, so it looks like a bug has been introduced in Language.Haskell.Parser at some point. Cheers, Simon
A B C D ghc yes no no yes hugs yes no no no nhc98 yes yes no yes Language.Haskell.Parser.parseModule no yes yes no report no no no no
... but I beg to differ with the row for the "report". Looking carefully at code examples A and B, notice the extra single space indentation on the second line:
** A: g xs = do ys <- workM xs if null ys then return [] else do zs <- workM ys return zs
I believe nhc98 is correct in parsing this as: g xs = do ys <- workM xs (if null ys then return [] else do zs <- workM ys return zs)
** B: g xs = do ys <- workM xs if null ys then return [] else do zs <- workM ys return zs
Likewise, isn't the following parse correct?: g xs = do ys <- workM xs (if null ys then return [] else do zs <- workM ys (return zs))
** C: f xs = case xs of y:ys -> case ys of z:zs -> zs
We all agree that this is a parse error.
** D: f x = case x of False -> do { return x; }
Although it is technically wrong to accept this, Simon and I believe it would be reasonable, because it is unambiguous. Regards, Malcolm
On Tue, Feb 22, 2005 at 11:14:22AM +0000, Malcolm Wallace wrote:
** A: g xs = do ys <- workM xs if null ys then return [] else do zs <- workM ys return zs
I believe nhc98 is correct in parsing this as:
g xs = do ys <- workM xs (if null ys then return [] else do zs <- workM ys return zs)
I don't think so: exp10 -> ... | if exp then exp else exp | fexp fexp -> [fexp] aexp The argument can't be an if-expression.
participants (3)
-
Malcolm Wallace -
Ross Paterson -
Simon Marlow