Merge happy-* library packages into a single happy library component

[sgraf812]

Triggered by the discussion in #288, we found that it would be preferable to merge all happy-* library packages into the library component associated with the happy executable. The reasons are:

• Less maintenance overhead compared to the status quo (see Should we make the happy-* packages public library components of happy? #288).
• happy does not have many dependencies, so there is almost no added value of splitting it into several libraries. For example, happy-backend-lalr does not take much longer to compile than happy-grammar.
• Multiple public library components as in Cabal 3.0 allow to retain the split, but none of the compilation time benefits apply because all components are built anyway Edit: wrong according to @phadej; see below. However, multiple public components might also be less well supported by stack and nix.

I will prepare a PR.

[phadej]

all components are built anyway.

Wrong. I didn't say that. I said solved for.

[Ericson2314]

I am very much against this for the reasons I wrote in #293 (review) (I keep on seeing the PRs first before the issues, sorry.)

[sgraf812]

Wrong. I didn't say that. I said solved for.

Fair enough. Sorry for misquoting you. Compile-times are not an issue with happy anyway.

everything will bleed back together

I honestly don't see what could "bleed back together" here, or what improved since the package split happened in the first place, apart from a proper module hierarchy.

What concrete evidence can you point to that justifies the increased maintenance overhead?
I would prefer that we inform our decisions based on said evidence, rather than daydreaming a vibrant composable ecosystem that we will never have.

Do note that the original motivation was reuse (in happy-rad). For that it doesn't matter whether we have multiple libraries or just one; what matters is that it is complete (and we fail at that for the CLI interface, as I argued in #286 (comment)). Beyond that, I prefer the solution that causes the least maintenance overhead, which is a single library component.

[Ericson2314]

concrete evidence

Let me flip this around. If we do multiple libraries in a single package, what evidence is there for concrete overhead? If no one wants to use new features like multi-package nix repl, multiple libraries per package, etc. what is even the point of these features being developed? Someone has to be the guinea pig.

Now, because we've had the multiple libraries, things have not bled back together. So I have no evidence of this happening in happy since the split, nor should I, because the remedy is in place. However, I've seen numerous examples of the architecture going to shit in many other projects, including GHC, projects at work, etc. etc. I can't share the work ones publicly but you can ask me privately if you like.

I always hoped that happy and alex could be the pioneer for doing things "the right way", i.e. with internal component boundary enforcement. Yes, they are smaller projects, but that makes it easier to demonstrate the viability of things. If we try shipping a multiple-libraries-per-package release and shit hits the fan, then we should gather up those bug s and get the HF to coordinate them being fixed.

[sgraf812]

Closed in favor of the design described in #288 (comment).