haskell / haskell/happy

Happy and template haskell

Open
#149 9 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.