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? 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? Thanks, - Vlad _______________________________________________ ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
This dependency on alex and happy to boot ghc has been annoying, but
wasn't that terrible until a while ago when some ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If happy was part of ghc, this would not have been an issue. As such I'd be on board with adding happy *and* alex as submodules into the `utils` folder. And thereby reducing the external boot dependencies of ghc! I believe - `compiler/ghc.cabal.in` would need to get a `build-tool-depends:` stanza for happy and alex, - `utils/genprimopcode/genprimopcode.cabal` same - `utils/hpc/hpc-bin.cabal` same for happy only. For `hadrian`, you'd need to make it aware of happy and alex packages in `hadrian/src/Packages.hs`. (Just follow other "util"s in there, e.g. unlit or touchy). In general hadrian should follow cabal dependencies properly. cheers, Moritz On Sun, Aug 2, 2020 at 3:43 PM Vladislav Zavialov <[hidden email]> wrote: > > 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? > 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? > > Thanks, > - Vlad > _______________________________________________ > ghc-devs mailing list > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
Big +1 on this. There area few experiments I'd like try with Happy that
I think this will help with, too. On 8/2/20 4:18 AM, Moritz Angermann wrote: > This dependency on alex and happy to boot ghc has been annoying, but > wasn't that terrible until a while ago when some > ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If > happy was part of ghc, this would not have been an issue. > As such I'd be on board with adding happy *and* alex as submodules > into the `utils` folder. And thereby reducing the external > boot dependencies of ghc! > > I believe > - `compiler/ghc.cabal.in` would need to get a `build-tool-depends:` > stanza for happy and alex, > - `utils/genprimopcode/genprimopcode.cabal` same > - `utils/hpc/hpc-bin.cabal` same for happy only. > For `hadrian`, you'd need to make it aware of happy and alex packages > in `hadrian/src/Packages.hs`. > (Just follow other "util"s in there, e.g. unlit or touchy). > > In general hadrian should follow cabal dependencies properly. > > cheers, > Moritz > > On Sun, Aug 2, 2020 at 3:43 PM Vladislav Zavialov <[hidden email]> wrote: >> 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? >> 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? >> >> Thanks, >> - Vlad >> _______________________________________________ >> ghc-devs mailing list >> [hidden email] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
In reply to this post by Vladislav Zavialov-2
Vladislav Zavialov <[hidden email]> 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? 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 [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
Ben Gamari <[hidden email]> writes:
> Vladislav Zavialov <[hidden email]> writes: > ... > 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 My apologies. The above should have read: > use the *produced* executable _______________________________________________ ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
In reply to this post by Vladislav Zavialov-2
Hi,
For solution b, Happy doesn't have to be a submodule. You can add it to hadrian/stack.yaml if you build with stack. See https://gitlab.haskell.org/ghc/ghc/-/commit/90e0ab7d80d88463df97bc3514fc89d2ab9fcfca where I had to do this. It may be possible to do the same for Cabal with hadrian/cabal.project but I've not tried it. Cheers, Sylvain On 02/08/2020 09:43, Vladislav Zavialov wrote: > 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? > 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? > > Thanks, > - Vlad > _______________________________________________ > ghc-devs mailing list > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
In reply to this post by Ben Gamari-2
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 [hidden email] 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 [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
FWIW I have a parser-generator implementation here https://github.com/simonmar/happy/pull/170 On Fri, Dec 4, 2020, 06:35 John Ericson <[hidden email]> wrote:
_______________________________________________ ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
In reply to this post by Vladislav Zavialov-2
Would you be happy to be a maintainer of happy?
Sorry, couldn't resist, but I ask seriously. - Oleg On 2.8.2020 10.43, Vladislav Zavialov wrote: > 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? > 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? > > Thanks, > - Vlad > _______________________________________________ > ghc-devs mailing list > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
I'll take the bait :) and offer co-maintain both Happy and Alex, on the
condition that we agree to make them submodules in GHC. John On 12/4/20 7:00 AM, Oleg Grenrus wrote: > Would you be happy to be a maintainer of happy? > > Sorry, couldn't resist, but I ask seriously. > > - Oleg > > On 2.8.2020 10.43, Vladislav Zavialov wrote: >> 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? >> 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? >> >> Thanks, >> - Vlad >> _______________________________________________ >> ghc-devs mailing list >> [hidden email] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [hidden email] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ghc-devs mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs |
Free forum by Nabble | Edit this page |