After some work, I have replaced jhcs front end with one using an AlternateLayoutRule and it passes ghc's parsing regression tests. I had to make some modifications so the code so it isn't as pretty as I'd like, I'll see if I can distill the essence out into something concrete. Incidentally, I found a particularly troublesome case for the current ghc rule out in the wild during my testing: -- Lining up |'s and indenting new blocks 4 spaces. A fairly common practice. bar x y = case x of Just z | y > z*2 -> case y of _ -> y | y > z -> y*10 _ -> 1 bar (Just 2) 3 => 30 --add a constant true guard that should be a nop bar x y = case x of Just z | y > z*2 -> case y of _ | True -> y <=== added a no-op guard | y > z -> y*10 _ -> 1 bar (Just 2) 3 => 1 The pattern match was fairly complicated making what happened pretty obscure. One of the main benefits I have found is being able to process the token stream between the lexer and parser, which drastically simplified my parser making it almost shift/reduce conflict free. I turn (+) and case into single lexemes and turned reservedids into varids for the keywords of unenabled extensions. John -- John Meacham - http://notanumber.net/