WIP Template-Haskell based version

fleex-x commented 2 years ago

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 commented 2 years ago

Have you talked to @int-index about this?

int-index commented 2 years ago

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 commented 2 years ago

Agreed combinators first is the right approach.

sgraf812 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@fleex-x Are you still pursuing this?

haskell / happy

WIP Template-Haskell based version #233