Happy and template haskell
- Dominant language
- Haskell
- Stars
- 322
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Description
I hope via https://github.com/ghc-proposals/ghc-proposals/pull/243 to make GHC able to use TH, but as GHC is not the sole user of happy, I figured I can get the ball rolling on brainstorming ideas now.
The first change I think would be to allow separating the grammar from the user written code. Happy could turn a `.y` files *without* any Haskell in between the braces into its representation of the grammar. Then, in another module, one writes all the production eliminators, named according to some convention. Finally, one imports happy as a library along with that grammar, and has a splice to generate what comes out of `.y` today.
Now, while the separation of grammar and eliminator seems like classic nice separating concerns, I'll wholly admit that using multiple completely separate ASTs with the same grammar is not likely to be useful in practice---it would be better to write a polymorphic AST and single set of polymorphic production eliminators.
The real benefit is now we have a chance to programmatically modify the grammar before parser codegen. Things like parameterized/macro rules and inlining (#148) could perhaps be done without as much, or any, support from Happy itself. User manipulation of the grammar could also allow it to be nicely split between multiple files, or more broadly, be compositionally constructed.
CC @sgraf812 @harpocrates
Contributor guide
Assessment
This issue has not been assessed yet.