happy

happy copied to clipboard

I'm seeing that happy generates Haskell files such as

happySpecReduce_2 nt fn (j::FAST_INT) tk _ CONS(_,sts@(CONS(st@HAPPYSTATE(action),_))) (v1`HappyStk`v2`HappyStk`stk')
     = let r = fn v1 v2 in
       happySeq r (GOTO(action) nt j tk st sts (r `HappyStk` stk'))

since the unreleased 2.0 version, I think.

While I understand that it's far easier to lean on GHC's CPP extension to generate parsers, doing so kind of implies --ghc.

If we want to go that route, can't we go all the way also get rid of the non---ghc mode of happy?

The fact that CPP is emitted at all (with or without --ghc) creates issues. For example, happy can't be used as a preprocessor with -pgmF.

So, ideally, there should be a mode to emit parsing code with all CPP conditionals resolved in some reasonable way.

Hmm. Perhaps that mode isn't the good old "generate Haskell code via String" backend? Unless...

I'm currently working on happy to implement a proper error recovery mode and wonder if all these different modes are necessary, because they are painful to maintain. GHC only uses -agc. I don't see any reason to pass different flags. Well, perhaps omitting -a to get a recursive ascent parser with explicit stack, but that reportedly leads to much larger parsers; plus, there's also a recursive ascent-descent mode available in https://github.com/knothed/happy-rad.

So if we are going to have breaking changes anyway, perhaps we can be more ambitious?

No longer an issue after #278.