haskell / happy

The Happy parser generator for Haskell
Other
276 stars 84 forks source link

No bootstrapping #169

Closed int-index closed 3 years ago

int-index commented 4 years ago

Currently, building happy requires a pre-built binary of happy.

It is, surely, elegant, in the same way a self-hosting compiler is elegant. But it also makes building purely from source more complicated than needed.

What we could do instead is parse .y and .ly files using parser combinators. But it would also be nice to avoid a dependency on another parsing library. Also, the currently existing hand-rolled lexers are written in continuation-passing style, so we'd need a library compatible with that.

So I developed a small, bespoke parsing library, specifically for happy, and it seems to work nicely. Patch here: #170

andreasabel commented 3 years ago

2021-02-15: It seems that happy still has some bootstrapping issues. At least, it does not work out-of-the-box.

I tried to build standard CI for happy using the https://github.com/Haskell-CI/haskell-ci tool, but it fails due to requiring happy already: https://github.com/andreasabel/happy/runs/1909119222

Couldn't happy be made independent of its own by

check[ing] in Happy-generated files

https://github.com/simonmar/happy/pull/170#issuecomment-679978211

Anyhow, you already had a long discussion about this at #175. It would be great if building happy would work out-of-the box with standard cabal commands (without requiring happy).

Ericson2314 commented 3 years ago

@andreasabel I think this is because the flag is manual and on by default: https://github.com/simonmar/happy/blob/f3848b6673fd274541c61806a34df2911a5c7fc6/happy.cabal#L148-L151

I would love to make that automatic, but that requires https://github.com/haskell/cabal/issues/7189. Maybe off by default would also be good, but that's a breaking change due to the attribute grammar stuff going away.