FWIW I have a parser-generator implementation here https://github.com/simonmar/happy/pull/170
On Fri, Dec 4, 2020, 06:35 John Ericson <john.ericson@obsidian.systems> wrote: > Seeing https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4560 stuck on > needing a new version of Alex reminded me of this. > > Ben raises a good point on Happy bootstrapping from itself making this a > pain, but I'd hope we could just get around this by vendoring the generated > happy parser in the happy repo. In fact their two ways to do this: > > - as a permanent change, in which case we'd want to write a script to > update the vendor instead of the custom sdist that is is the point of the > Makefile. > > - in a separate "master-sdist" branch of generated sdists, which GHC would > track with the submodule instead of master. > > While I'm rarely for vendoring generated code, breaking a bootstrap cycle > is a pretty darn good reason. Also this is rather benign case of bootstrap > artifact vendoring as: > > - Generated happy code is a lot easier to understand than machine code at > scale > > - Ken Thompson attacks on the parser scare me less than elsewhere in the > compiler > > Finally If all that is still too ugly, well, it would be nice to have a > parser-combinator implementation of the same functionality that can double > as a oracle for testing. > > Cheers, > > John > On 8/4/20 1:21 PM, Ben Gamari wrote: > > Vladislav Zavialov <vladis...@serokell.io> <vladis...@serokell.io> writes: > > > Hi ghc-devs, > > I’m working on the unification of parsers for terms and types, and one > of the things I’d really like to make use of is a feature I > implemented in ‘happy’ in October 2019 (9 months ago): > > https://github.com/simonmar/happy/pull/153 > > It’s been merged upstream, but there has been no release of ‘happy’, > despite repeated requests: > > 1. I asked for a release in December: > https://github.com/simonmar/happy/issues/164 > 2. Ben asked for a release a month ago: > https://github.com/simonmar/happy/issues/168 > > I see two solutions here: > > a) Find a co-maintainer for ‘happy’ who could make releases more > frequently (I understand the current maintainers probably don’t have > the time to do it). > b) Use a development snapshot of ‘happy’ in GHC > > Maybe we need to do both, but one reason I’d like to see (b) in > particular happen is that I can imagine introducing more features to > ‘happy’ for use in GHC, and it’d be nice not to wait for a release > every time. For instance, there are some changes I’d like to make to > happy/alex in order to implement #17750 > > So here are two questions I have: > > 1. Are there any objections to this idea? > > > I'm not entirely keen on the idea: while the cost of the submodule > itself is pretty low (happy is a small package which takes little time > to build), I am skeptical of addressing social issues like happy's lack > of maintenance with technical solutions. Ultimately, shipping happy as a > submodule would merely kick the current problem down the road: > eventually (when we release GHC) we will need a happy release. Unless > the underlying maintainership problem is addressed we will end up right > back where we are today. > > Moreover, note that happy requires happy as a build dependency so we won't be > able to drop it as a build dependency of GHC even if we do include it as > a submodule. > > For this reason, I would weakly prefer that we first find a maintainer > and try to get a release out before jumping straight to adding happy as > a submodule. I will try to bring up the matter with Simon Marlow to see > if we can't find a solution here. > > > 2. If not, could someone more familiar with the build process guide > me as to how this should be implemented? Do I add ‘happy’ as a > submodule and change something in the ./configure script, or is > there more to it? Do I need to modify make/hadrian, and if so, then > how? > > > It will be a tad more involved than this. We will need to teach the > build systems to build Happy, use the configure executable, and update > the source distribution packaging rules to include the new submodule. > Moreover, happy (unfortunately) has a make-based build system which will > need to be used to generate its parser. > > Updating the build systems likely won't be difficult, but there isn't clear > documentation on what it will involve. This will really be a matter of > finding a similar existing case (e.g. genprimops, perhaps?), following > it as a model, and figuring out how to fill any gaps. > > Moreover, build system logic is inevitably a bug-nest; adding the same > logic twice greatly increases the chance that we will have (two sets of) > bugs that will only be caught post-release. For me, this underscores the > need to first try to make the existing decoupled situation work before > moving to a vendored solution. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing > listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
