happy

happy copied to clipboard

We have some discussion in https://github.com/simonmar/happy/issues/167 and https://github.com/simonmar/happy/issues/149, but let's lay out the first steps in a separate issue.

• [x] get rid of the extra template preprocessing step (https://github.com/simonmar/happy/pull/179)
• [x] make bootstrapping optional (https://github.com/simonmar/happy/pull/175)
• [ ] Make parser combinator bootstrap path simpler by reusing ReadP from base (see https://github.com/simonmar/happy/pull/175#issuecomment-752951456)

At this point the bootstrap will be as simple as it's ever been, and we still support GHCs 7 and up, so I would like to do a release.

Afterwords I would like to take more radical changes:

• [ ] Start splitting up package into (sub) libraries
  • [ ] Maybe factor out "run time" into one such library, rather than shoving it in the same file as the generated output from templates
• [ ] Maybe drop support for old cabal

Start splitting up package into (sub) libraries

I think @knothed already made some progress in that direction. Since hackage doesn't support multi public library packages yet, we settled on one cabal file for each subcomponent, which means more administrative overhead each release. Maybe some script/configure/Makefile can automate the process.

The current example is at https://github.com/knothed/modular-happy. Still a few refactorings away from being feasible to merge back into happy mainline, but hopefully not too long. The general ideas of https://github.com/simonmar/happy/issues/167#issuecomment-780591344 are still valid, there's but one more package: happy-executable (maybe happy-cli would be better), that provides CLI parsing facilities. We were prveiously wrangling the different design options and arrived at a satisfying one that David is going to implement in the next weeks. Here's a sneak peek of a main function that includes support for the RAD extension (which ultimately will live in a different package than mainline happy):

main = do
    options <- parseOptions =<< getArgs
    grammar <- try $ runFrontend (frontendOpts options)
    (action, goto, lr1Items, unused_rules) <- runMiddleend (middleendOpts options) grammar
    case backend options of
      Normal opts -> runBackend opts grammar action goto
      RAD opts -> runRADBackend opts grammar action goto lr1Items unused_rules

This seems like an acceptable maintenance overhead for extension developers, compared to having to closely follow the happy GH repository.

This way we can also make happy and happy-boot into separate executables, replacing the complicated flag-based logic.

What is the way forward here? Does this issue still apply?

I would like us to take a critical look at what we're trying to achieve. Why wouldn't a single library happy-lib suffice?

Happy 2.0 shipped with said happy-lib. Let's close this issue and perhaps open a new one if there are any open TODOs here that apply. I don't currently see any.