happy emits code using -XCPP even in the absence of --ghc

[sgraf812]

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?

[int-index]

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.

[sgraf812]

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?

[sgraf812]

No longer an issue after #278.