Using a development snapshot of happy

[John Ericson]

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> 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 list
> ghc-devs at haskell.org
> http://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/20201203/ee7bb25b/attachment-0001.html>