GHC Steering Committee seeks input from industrial Haskell users

[maxigit]

@david-christiansen

Do you think that this makes things better, though?

The short answer is no, for me it’s trying to solve a problem which in my experience doesn’t exists.

I’ll explain. GHC is the most conservative software I ever seen. We use to have a joke in one of my previous work “temporary means forever”. That stands for GHC. I’ve never seen any extension, experimental or not being changed or removed. One would expect that once a space design has been explored and battle tested all the mini extensions composing a feature would be merged into one. That doesn’t happen. Or we could think that once it’s been stabilised it actually becomes the default and the extension becomes “obsoletes”, it doesn’t happen either because GHC has to follow the specification.
Fair enough, we could then expect that once the spec get updated (every 12 years) then the previous anguage got forgotten about and all adopted extionsion become obsolete (or better removed). That doesn’t happend either. GHC is still Haskell 98 plus 100 something extensions (doing in ghci :set -X<tab> gives me 252 possibilites, I guess I should divide by 2 that left 126 extensions).

Nothing get ever removed from GHC, so as I industrial user I can confidently use any of them, I know they’ll still be there in 10 years. That’s what I’ve been doing and I have never been bitten by doing so.

I might not count as a industrial user. I’m the sole developper doing a in-house software with about 3 users (including me). I get (sort of ) paid for it, and it’s been used daily since 2016. It started with lts-5.9 and use now lts-20.*.

Now, I might be missing the quick change at the beginning of the life of an experimental extension, but so will other industrial user for the same reason. Upgrading to a new version of the compiler is a painfull process and I do as least as possible. The usual culprit are base being bumped, internal refactoring breaking TH , abadonware package needed care etc …

So I wait for things to settle before upgrading to a new version of GHC. By that time every extensions availbale will there for eternity.

[jaror]

(Disclaimer: I’m not an industrial user)

@maxigit

I’ve never seen any extension, experimental or not being changed or removed.

RankNTypes was infamously changed recently which broke a whole lot of code and spawned the new DeepSubsumption extension that undoes the change. Also, ExistentialQuantification has changed and will probably soon change again, see the other thread (that is a rather trivial change, but it could break code).

@maxigit

we could think that once it’s been stabilised it actually becomes the default and the extension becomes “obsoletes”

GHC2021 has become the default. Removing old extensions just breaks existing code for little reason. I guess you could argue it would improve discoverability of the remaining extensions, but that doesn’t weigh up against the breakage it would cause; the categorisation proposed here would be a better way to improve discoverability in my opinion.

[maxigit]

@jaror

GHC2021 has become the default.

It is still an extension set. What I mean by remove is when an extension is adopted the doc could me moved the corresponding part in the syntax manual and the fact that it used to be an extension all forgotten. So that when you looked at Haskell 2010 for example you have a standalone thing, not Haskell 98 + x y and z.

[nomeata]

@maxigit

What I mean by remove is when an extension is adopted the doc could me moved the corresponding part in the syntax manual and the fact that it used to be an extension all forgotten. So that when you looked at Haskell 2010 for example you have a standalone thing, not Haskell 98 + x y and z.

I agree. I hope we will get to the point where the latest GHC20xx is perceived not as a set of extensions, but as a wholesome language edition, and the documentation structure hopefully will support that.

The old editions (Haskell2010, GHC2021, all the various extensions to these base lines) may still be supported to not break code lying around untouched. But hopefully developers who write fresh code, or who keep following the GHC20xx language editions with their actively maintained code, will no long have to think of so many extensions as features.

[AntC2]

@maxigit

I’ve never seen any extension, experimental or not being changed or removed.

DatatypeContexts was removed by GHC2010 – chiefly so that we could experiment with bringing back the syntax but with more helpful semantics.

The current extensions around DuplicateRecordFields/Disambiguation and friends are regarded as experimental and liable to change. (That is, some of the implementation detail might change, not the proposed syntax: the implementation has run into some fishhooks.) And amongst the ‘friends’, NoFieldSelectors takes away a H98 feature.

Nothing get ever removed from GHC

Not true looking back over ~25 years; but I agree GHC has been getting more timid over the past (say) 5 years. Since DatatypeContexts is still ‘on the books’, there’s a risk someone’s still using it, so can we actually introduce something more helpful under that name?

I might not count as a industrial user.

Yeah. I’m pretty sure David’s o.p. wasn’t aimed at me (as a hobby user), so I’ve kept off this thread.

[david-christiansen]

@AntC2

Yeah. I’m pretty sure David’s o.p. wasn’t aimed at me (as a hobby user), so I’ve kept off this thread.

That’s right - this proposal was written specifically to address challenges we’d heard of from larger teams with mixed levels of Haskell expertise. If it helps enough of them significantly and doesn’t impose unacceptable costs on hobbyists, researchers, enthusiasts, and teams of experts, then I think it’s a win - if not, then back to the drawing board!

[maxigit]

This it why I’ve been keeping out of the proposal itself.