Remove UHC

[BardurArantsson]

OK, here are the commits for removing the JHC/UHC compiler flavours.

There are a couple of opportunities for removing some function parameters at this point because they've become unused, but I'm not sure we can do that per compatibility requirements...? It's mostly the defaultInstallDirs and defaultInstallDirs' functions I'm thinking of.

[23Skidoo]

/cc @atzedijkstra

[dcoutts]

Makes sense for JHC. For UHC I think it is worth double checking with the UHC authors. Back in the day both sides went to some trouble to get UHC supporting Cabal and Cabal supporting UHC.

[atzedijkstra]

I keep UHC alive, that is, keep it compilable and working. Although currently not further developed I’d appreciate if the Cabal support is also kept alive, that is, kept compilable (not necessarily working), so if work on UHC is ever picked up again the code is not gone. regards Atze

…

-- Atze Dijkstra

On 30 May 2018, at 00:33, Duncan Coutts ***@***.***> wrote: Makes sense for JHC. For UHC I think it is worth double checking with the UHC authors. Back in the day both sides went to some trouble to get UHC supporting Cabal and Cabal supporting UHC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[23Skidoo]

OK, let's remove JHC, but not UHC.

[23Skidoo]

Given that we didn't remove Hugs, YHC or NHC from here, we should leave JHC and UHC here as well.

[BardurArantsson]

Are you sure it wasn't just missed accidentally?

I understand that there might theoretically be Setup.hs code out there that relies on these, but wouldn't it be to "break it at compile time" rather than runtime?

[23Skidoo]

We should either remove {hugs,nhc98}-options from here as well, or keep jhc-options.

[hvr]

Removing those fields from the grammar would result in parser errors/warnings being emitted by newer lib:Cabal; if we want to remove them, we should only make it a parser warning/failure for newer cabal-version specs; while older specs should be silent about the occurence.

/cc @phadej

[BardurArantsson]

Yeah, I've "moved" this to "knownField ..." for precisely the reasons that @hvr mentions.

[23Skidoo]

Can you please fix the TODO here while you're at it?

[BardurArantsson]

I intentionally did not to avoid mixing up the "remove JHC" change with an "expand the Cabal API" change.

I'm assuming that adding the knownCompilerFlavors will implicitly expand the Cabal API... is that assumption right, and do we want that?

If so, it'll happily do a folllow-up for that.

(I suppose I could add a Haddock note about the API only being for testing, or something?)

[23Skidoo]

LGTM modulo comments.

[tom-bop]

Is JHC no longer usable/under development?

[BardurArantsson]

@atzedijkstra Please reconsider asking the Cabal maintainers to keep the UHC code around.

I'll preface this by saying that it actually applies to a lot of Cabal features beside UHC, so I apologize if this sounds like I'm going on a rant about UHC. It's just that I've been thing a lot about this type
of thing in the context of general software maintenance and this case provides a nice concrete example where I also care enough to try to make a thorough argument :).

(Hope I'm doing the quoting thing correctly.)

@atzedijkstra

I’d appreciate if the Cabal support is also kept alive, that is, kept compilable (not necessarily working), so if work on UHC is ever picked up again the code is not gone.

I can certainly understanding wanting to have others "maintain" the code, but I think this is the wrong tradeoff -- unless you or someone else who actually works on UHC can commit to actually maintaining the UHC-related code in a working state. That would at least probably involve adding Cabal+UHC integration tests of the "can it compile a hello-world cabal package?" type.

Here are my reasons:

• By keeping the code around (hence: it must compile), there's a cognitive cost for every single person who ever thouches these files. This leads to a "fear to change" because who knows if UHC/$OTHER_COMPILER will break when I change anything in the code in this area? One can say "well, it's not that important if UHC breaks, just ignore that", but many humans don't quite work that way, and fear of breakage is already a constant factor in a project as complex as Cabal/cabal-install.

• It casues the Cabal API to be more complex than necessary, see the now-unused parameter to defaultInstallDirs' and prevents simplification. (Whether that simplification can happen right now is another matter, but that just has more to do with Cabal API stability guarantees.)

• It's practically a certainty that very few Hackage packages will actually compile with Cabal+UHC (no test coverage whatsoever AFAICT) due to the prevalence of GHC extensions in "basic" packages, so why pay the continuing cognitive cost of keeping the UHC support compiling? The code will always be there in the Git repository history and can always be brought back by someone who's motivated to do so. This would mean that the cost of maintenance falls upon the right people, namely those who want to use/maintain UHC, and not everybody else[1]. Should it ever happen, ressurrecting code like this should be a pretty simple thing once you have a working compiler you can actually test with. Heck, it might even motivate that person to work towards a more "standardized" API so that compiler-specific workarounds wouldn't even be necessary.

  Let's stick to the YAGNI principle absent a good reason not to. (I realize that it can be painful to have to let go of code one's worked hard on, but sometimes it's just time to let it go.) The number of times the YAGNI principle has failed me (through many, many projects) can be counted on one hand.

• (More of a project-level concern:) We must be more aggressive about removing unmaintained code which this certainly is. The Cabal/cabal-install code base is impenetrable enough as without having to keep track of which code it's fine to break on a whim (UHC support) vs. which code it isn't OK to break.

If someone were to commit to actually making sure we keep this working by e.g. adding tests, then I'd obviously have much less of a problem with keeping it, but as-is I see only downsides to keeping it and no upside.

Regards,

Bardur

Footnotes:

[1] Obviously, if UHC were hugely popular, then the there's a reasonable case to be made that the Cabal/cabal-install developers should support it without "upstream" support simply to avoid becoming irrelevant, but sadly that's not the world we live in. Personally, I'd love to have a more diverse compiler landscape for Haskell, but it's looking like a more and more remote possibility due to the speed of change in GHC and the Haskell ecosystem's usage of the new and shiny features.

EDIT: Formatting.

[23Skidoo]

For me personally, keeping UHC bits compilable is not a huge burden, but other contributors's mileage may vary.

[BardurArantsson]

@23Skidoo I'm not saying that the UHC bit is by itself a problem, in isolation. It's adding its own little burden to the overall maintenance cost for every maintainer and that it simply isn't worth that extra additional cost to keep it compiling. It's like one of the "straw that ends up breaking the camel's back" type situations.

[gbaz]

I think this is a plain straw, not one that relates to any camel. There’s other things that eventually should be trimmed and will bring noticable benefit to the codebase. Here, the overhead is minimal, sonce the design of cabal is conducive to having an enumerated list with a few more compilers listed.

[BardurArantsson]

@gbaz It's not just an enumerated list. As I've mentioned there are a few possible API simplifications that this could lead to. (EDIT: Plus, possibly dead code that could be removed. I haven't investigated further on that.)

[BardurArantsson]

@23Skidoo Any comments on my review questions/comments?

[23Skidoo]

We can merge the uncontroversial JHC bits, I think I'll do it later today.

[BardurArantsson]

Cool, thanks!

[23Skidoo]

Merged the JHC bit, rebased against master.

[Mistuke]

I too don't see that see the reason to drop UHC support. Cabal is supposed to be abstracted in a way that this shouldn't matter much.

I would very much hate if Cabal becomes a GHC specific tool. In my opinion keeping other implementation around is a great way to insure the API remains abstracted cleanly.

Besides the maintenance burden is quite low anyway. Popularity shouldn't be a reason to remove something. By that argument the only compiler that should be supported is GHC.

[BardurArantsson]

Ok, I'm done tilting at windmills, I guess...

@23Skidoo Can you please remove my "commit bit"? I guess there's just too much of a philosophical difference between me and the maintainers when even simple things like YAGNI are controversial when we're talking about a "feature" that's perhaps relevant to tens of users at most. It's just to draining to periodically get my hopes up, so I'd rather just let go completely of any idea of trying to contribute major cleanups to Cabal in future. (This state of affairs saddens me, but I guess it's just time to move on. Thanks to all the maintainers/contributors for all the hard work you do, btw.)

@atzedijkstra Just out of curiosity, is the statement on UU-ComputerScience/uhc#85 (comment) about not being able to build libraries at all via Cabal+UHC still true? If so, then how on earth can it possibly be relevant to keep UHC "support" in Cabal? (I'll not that the issue has been open for 2 years now. How likely do we think it's going to be fixed/implemented?)

EDIT: Oh, I forgot: You might want to know that the UHC README points to non-existent URL.