<div dir="auto">FWIW I have a parser-generator implementation here <a href="https://github.com/simonmar/happy/pull/170">https://github.com/simonmar/happy/pull/170</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020, 06:35 John Ericson <john.ericson@obsidian.systems> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Seeing <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4560" target="_blank" rel="noreferrer">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4560</a>
stuck on needing a new version of Alex reminded me of this.</p>
<p>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:<br>
</p>
<p>- 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.<br>
</p>
<p>- in a separate "master-sdist" branch of generated sdists, which
GHC would track with the submodule instead of master.</p>
<p>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:</p>
<p> - Generated happy code is a lot easier to understand than
machine code at scale</p>
<p> - Ken Thompson attacks on the parser scare me less than
elsewhere in the compiler</p>
<p>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.</p>
<p>Cheers,</p>
<p>John</p>
<div>On 8/4/20 1:21 PM, Ben Gamari wrote:<br>
</div>
<blockquote type="cite">
<pre>Vladislav Zavialov <a href="mailto:vladislav@serokell.io" target="_blank" rel="noreferrer"><vladislav@serokell.io></a> writes:
</pre>
<blockquote type="cite">
<pre>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):
<a href="https://github.com/simonmar/happy/pull/153" target="_blank" rel="noreferrer">https://github.com/simonmar/happy/pull/153</a>
It’s been merged upstream, but there has been no release of ‘happy’,
despite repeated requests:
1. I asked for a release in December: <a href="https://github.com/simonmar/happy/issues/164" target="_blank" rel="noreferrer">https://github.com/simonmar/happy/issues/164</a>
2. Ben asked for a release a month ago: <a href="https://github.com/simonmar/happy/issues/168" target="_blank" rel="noreferrer">https://github.com/simonmar/happy/issues/168</a>
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?
</pre>
</blockquote>
<pre>
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.
</pre>
<blockquote type="cite">
<pre> 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?
</pre>
</blockquote>
<pre>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
</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank" rel="noreferrer">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
</blockquote></div>