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 > ghc-devs@haskell.org > http://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
