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,
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
FWIW I have a parser-generator implementation here
https://github.com/simonmar/happy/pull/170
On Fri, Dec 4, 2020, 06:35 John Ericson
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
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 h
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/ca
Ben Gamari writes:
> Vladislav Zavialov 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
signature.asc
Descr
Vladislav Zavialov 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 bee
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 <
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
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 r
10 matches
Mail list logo
