On 29/11/2009 19:40, Duncan Coutts wrote:
On Fri, 2009-11-27 at 10:28 +0000, Simon Marlow wrote:
On 26/11/2009 11:50, Ian Lynagh wrote:
Wed Nov 25 15:19:01 PST 2009 Ian Lynagh<[email protected]>
* Fix a bug in alternative layout rule
M ./compiler/parser/Lexer.x +1
Great that you've implemented this. Are you planning to do a proposal
for Haskell 2011?
It doesn't particularly bother me that the simpler rule can't handle
some of the obscure cases.
Here's the main one it cannot cope with that bothers me:
foo x = case bar x of
Pattern1 -> ...
Pattern1 -> ...
where
baz = ...
The new layout requires it to be:
foo x = case bar x of
Pattern1 -> ...
Pattern1 -> ...
where
baz = ...
Right. That one isn't fixable, because there's no way for the algorithm
to know that the 'where' should close the layout context introduced by
the 'case', without knowing more about the syntax. If we were to keep
extending the new layout rule to handle more of these cases by adding
more knowledge about the Haskell grammar, eventually it would be the
same as the current layout rule.
I'm actually quite surprised how often we really do use the "parse
error" feature of the current layout rule.
Another slightly odd one is:
if p c then do s<- munch p; return (c:s) else pfail
which has to be
if p c then do s<- munch p; return (c:s)
else pfail
This one is fixable: the then/else pair should behave like brackets, so
that 'else' can close a layout context.
> So I'm not convinced. If the tradeoff is between ugly code in my
> modules or the status quo of ugly code in ghc's lexer/parser then I'm
> happy to stick with the status quo.
The new code isn't really that much simpler, in that it's full of
special cases. It is conceptually simpler in the sense that it is an
independent pass, rather than a collaboration between the parser and lexer.
I think this is a worthwhile experiment. Various people have said to me
that implementing the layout rule correctly is a major obstacle in
building a Haskell implementation.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
