WIP Template-Haskell based version

[fleex-x]

trafficstars

Here I am writing a template-haskell version of happy to generate code directly in (TH.Q TH.Exp) and use it with the template-haskell extension. @kirelagin helps me with this.

What is going on:

• I've created a class that gives functionality to generate code. Also I've added its instances to generate strings (like in https://github.com/haskell/happy/pull/218) and abstract representation from Language.Haskell.TH.

• I am rewriting ProduceCode.lhs with code-combinators. As I plan, when I rewrite it all, it will immediately be able to generate template-haskell-based parsers (because of CodeGen TH.Exp instance).

What do you think about approach I am taking here? Is it nice or I have to change something in it?

[Ericson2314]

Have you talked to @int-index about this?

[int-index]

We talked with @kirelagin about it, he's supervising this effort. My request was to break it into small parts. First let's get the combinators themselves merged, and then start to rewrite the code gen in small steps, where each of them touches no more than 30-50 lines, easy to review and bisect if we miss something that is not semantics-preserving.

[Ericson2314]

Agreed combinators first is the right approach.

[sgraf812]

I'm a bit vary because the combinators library (and with it, the regular happy backend) currently depends on template-haskell. I sure hope that the regular happy executable will not need TH to build?!

[int-index]

I sure hope that the regular happy executable will not need TH to build?!

This could be arranged with CPP and build flags, but why is that important?

[sgraf812]

Because GHC has alex/happy as a boot dependency and that usually means we can't use TH. But you're probably right in that it's nothing worth worrying about, because we use happy as an executable to generate code, and one that we don't need to build with the stage1 compiler (say).

Of course it also means we can't use new shiny TH splices in GHC's happy parser, but we can't currently use TH splices in GHC's build to begin with, so that's a non-issue.

TLDR; fine. I do wonder though about compatibility to other Haskell compilers, but that bridge probably has been burned a while ago.

[Ericson2314]

Can we start with stuff like this https://github.com/haskell/happy/pull/218 ? It is a clear improvement, and also no TH dependency. Not saying we should never do the TH, but in the interest of taking small steps at a time and easy reviewing, I think it could be good to start with that.

[harpocrates]

TLDR; fine. I do wonder though about compatibility to other Haskell compilers, but that bridge probably has been burned a while ago.

I assumed the existence of the -g flag implies that without -g the code is vanilla enough that any Haskell98 compiler would accept it. OTOH, I remember there were a slew of small bugs on the non--g codepath, so I fear it doesn't get much use.

[sgraf812]

The dependency on TH is mostly problematic if you want to build happy exe on non-GHC. Codegen should be unaffected and brokenness the same as today.

[int-index]

@fleex-x Are you still pursuing this?