Could GHC remove old extensions?

[AntC2]

@santiweight

What it [a long set of extensions] gives me is a list of 50 extensions that may or not work together.

Then switching on some of them permanently hasn’t fixed anything: they still might not work together – or the 40 that are on permanently might not work together with the extra 10 you want for your project. Note that MultiParamTypeClasses doesn’t work too well without FunctionalDependencies, then adding OverlappingInstances (or rather the OVERLAP* pragmas) don’t work together too well, so you usually have to switch on UndecidableInstances which sounds scary: which of those do you want permanently on?

@santiweight

Perhaps I have to ask an even more fundamental question: do we want to remove extensions?

This question is: do ‘we’ want to make some extensions permanently switched on? I say No.

Do I want to to remove extensions? Yes. Now that I see how much violence Dependent Haskell is doing to the syntax of the language, I want to remove all those warts, and ask GHC high command to start the design again to achieve the same functionality (if that’s what they want) but be no more intrusive than FunctionalDependencies.

I have a similar feeling about PatternSynonyms: now that we know how to get them to play nicely (which wasn’t at all clear when the work started), please now throw away the current form of declarations and start again.

[AntC2]

@santiweight

Unless I’m wrong btw, TypeInType is now permanently part of GHC, so there is certainly precedent for merging extensions into the core language.

I can independently set or not set PolyKinds, KindSignatures, DataKinds. So no those are not permanently merged. You’re just wrong.

Under the hood, GHC’s type mechanism does use PolyKinds (Constraint vs Type, for example) with type-in-type internally. That’s invisible to me if I switch off those extensions (except perhaps grinning through in error messages). That’s about the compiler implementation, not “core language”. It doesn’t set any precedent. You seem unable to distinguish a language vs a compiler.

[Abab9579]

Lol haskellers too much love choice, so that they got buried in loads of choice.
(From non-haskeller I heard that it is one of the real barriers against adopting haskell)

[atravers]

@Abab9579

I heard that [loads of choice] is one of the real barriers against adopting haskell Haskell

• https://www.haskell.org/definition/haskell2010.pdf
• https://www.haskell.org/definition/haskell98-report.pdf

…but if that’s still too much choice, there’s always Standard (since 1997) ML.

[Abab9579]

You know… I meant the extensions without which it is impossible to code.

[jaror]

@santiweight

Mu - which is a dialect, and not public; diverged heavily from GHC

They did mention they are researching if it is possible to merge with GHC. It’s really only the back end that is completely different.

As for other compilers:

• UHC is dead, but one of the authors did want to take the best parts from it and start a new compiler project with that.
• The Helium Haskell compiler has aims to become Haskell2010 compliant, but development is going slow (it is basically developed by a single professor and his PhD students).
• @csabahruska has done some things with JHC in 2018, but I don’t know if there are bigger plans.

[schuelermine]

Which ones are that, in your opinion?

[atravers]

Does it matter? We’re all going to have our own opinions on what [now ] are “the extensions without which it is impossible to code”, and they will change as the Haskell extend-a-thon continues. I think our new ED said it best, albeit in a somewhat-different context:

@david-christiansen

Meta-work spent figuring out how to do our work is important, but there’s definitely diminishing returns as more is done, and I worry that opening this can of worms right now will mean not getting other things done.

But if you really, really still want to discuss this, I humbly suggest starting a new thread…

[Abab9579]

I do mean how there are creep of extensions, which is IIRC unique to haskell. Also causing 2^N compat problems.

Seriously, any clean-up work could be great - surely not everyone will agree which is worth in the standard as a permanent residence, but this extension creep is not sustainable either.

Tho we cannot decide because choices has to be offered. I dislike that part.

[AntC2]

@santiweight

a list of 50 extensions that may or not work together.

I’ve just caught up with Richard’s remark and watched the video:

@rae

As a timely example, my video today is about how with only -XFlexibleInstances, …

… that doesn’t “work together” with H98. And if any extension were to be non-optional, -XFlexibleInstances would be a strong candidate, as Richard says.

To counter some earlier snootiness about Hugs: -XFlexibleInstances is on in HugsMode, but it doesn’t cause the trouble Richard describes. That is, you can still reorder the decls in your file, and Hugs gives the same response. Specifically, it rejects the program precisely because it’s applying the Monomorphism Restriction eagerly, as compared to GHC. (It seems the Hugs team 16 years ago at least, adopted one of the strategies Richard speculates on. Would be interesting to know why.)

[Las]

What extensions if merged would simplify GHC? Syntactical extensions seem to me like they’re easy to support optionally, but perhaps supporting disabling QuantifiedConstraints is not trivial, because you need to then detect when you’re making use of the functionality.

For extensions where this is not the case, I don’t see any reason to disallow disabling them, when new meta-extensions like GHC2021 will probably happen again.