AlternateLayoutRule

[Ian Lynagh]

On Tue, May 13, 2014 at 09:32:31PM +0100, Simon Marlow wrote:
> On 13/05/14 15:04, John Meacham wrote:
> >Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am
> >having trouble finding information about it. Is it based on my
> >proposal and sample implementation?
> >http://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html
> 
> Yes it is, but I think we had to flesh it out with a few more cases.
> Ian will know more, he implemented it in GHC.
> 
> I'm not sure what we should do about it.  I think Ian's motivation
> was to experiment with a view to proposing it as a replacement for
> the layout rule in Haskell', but (and this is my opinion) I think it
> ends up not being as clean as we might have hoped, and the cases
> where it doesn't work in the same way as the old rule aren't easily
> explainable to people.
> >
> >I ask because I was going to rewrite the jhc lexer and would like to
> >use the new mechanism in a way that is compatible with ghc. If it is
> >already using my code, so much the better.

It's based on your code, but I had to essentially completely re-write it
to work with the way that GHC's parser works; I don't think sharing the
code will be feasible.

I also fixed some bugs (e.g. I think that with your code,
    foo = let { x = x }
          in x
turns into something like
    foo = let { x = x }
          } in x
) and made some tweaks after trying it on GHC+bootlibs, but I don't have
details to hand.

However, the consensus was that the new rule has too many cases, due to
trying to match the old rule as closely as possible, and despite that it
doesn't have the advantage that it is a drop-in replacement. ISTR Cabal
in particular needed several changes to compile with it
(0aba7b9f2e5d8acea156d575184a4a63af0a1ed3). Most of them were code of
the form
    case e of
    p -> e'
    where bs
needing the 'where' clause to be less indented.

The plan, yet to be implemented, was to remove some of the cases of the
new rule, making it easier to understand, specify and implement, at the
expense of breaking more code when the switch is flipped.

Ideally, there would be a period during which compilers would check
during compilation whether the new rule would give a different token
sequence to the old rule, and warn if so.


Thanks
Ian