search

haskell / happy

The Happy parser generator for Haskell
Other
291 stars 84 forks source link

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

Closed sgraf812 closed 4 months ago

sgraf812 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 4 months ago

No longer an issue after #278.