Using a development snapshot of happy

Fri Dec 4 06:17:03 UTC 2020

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 at 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 <vladislav at serokell.io> <vladislav at 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 at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201204/09d92fdc/attachment.html>