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