WIP Template-Haskell based version #233
Conversation
fleex-x
force-pushed
the
template-haskell-version
branch
from
8a7331f to
6cae39d
Compare
…d Syntax.intE. `A.` in [A..5] is interpreted as a module name, so a space after `A` is needed here. Change type in Syntax.intE because of (abs (minBound :: Int)) doesn't work correctly.
I used wrong precedence in patter-generating inside Syntax.clause, so no brackets were generated when they were needed.
Now such listings are in alphabetical order.
Put correct package-description in cabal-file.
Now it is possible to avoid frequent use of mkName in code.
|
Have you talked to @int-index about this? |
|
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. |
|
Agreed combinators first is the right approach. |
|
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 |
This could be arranged with CPP and build flags, but why is that important? |
|
Because GHC has 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. |
|
Can we start with stuff like this #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. |
I assumed the existence of the |
|
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. |
|
@fleex-x Are you still pursuing this? |
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 ProduceCode using syntax combinators #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?