Could GHC remove old extensions?

#12

More to the point: a huge proportion of the tutorial materials are written around the Language Report. They don’t even reflect the FTP library changes. This is particularly awkward, because List functions feature so prominently in tutorials.

To answer that last point first: Yes, Haskell 98 standard is industrial strength: it’s all you need to implement the Prelude in the H98 Report; and people wrote substantial applications with it. For example, a compiler called “GHC”.

Hugs includes features way beyond H98. So it is industrial strength; and you can still download it; and you can still download its source and compile that. I use Hugs more often than GHC. It doesn’t support DeriveFunctor, and I certainly don’t want that sort of functionality taken for granted – neither do I want a compiler with type-in-type; neither do I want to ban punning.

But that’s exactly what you’re doing: Who says any particular extension is “cruft”? Keep your prejudices out of it.

Really what inconvenience is a long set of extensions causing you? Especially considering you can get those with GHC2021, as @adamgundry points out. Aren’t there more important things for the GHC team to get on with?

#13

You couldn’t be more wrong: GHC didn’t support all of the features in H98, as at 1998. That’s partly why the standard wasn’t actually finalised until 2002 – so that GHC could catch up.

It was Hugs that was the most fully featured compiler in 1998. It was so powerful, GHC was built in it.

1 Like
#14

I’d like to return to the question the original post asked:

I am only asking whether or not they can be removed

Sure! It’s true that removing extensions (that is, keeping them on permanently) would push us further from the Haskell standards, but I personally don’t see that as a hard barrier. It’s a negative, yes, but not a hard barrier. We’ve already done this several times: making Applicative a superclass of Monad, generalizing the types of the Data.List functions, auto-generating Typeable instances for all datatypes, and more I’m sure.

One real challenge here, though, is choosing which extensions to remove (of course). In my experience, even extensions that have lived benignly for a long time have dark corners. As a timely example, my video today is about how with only -XFlexibleInstances, you can cause GHC to care about the order in which declarations are written in a file. Would we want that on by default? Possibly, but it makes the behavior of the language harder to predict.

My bottom line: we absolutely can remove extensions. The harder question is which ones we should remove.

3 Likes
#15

Do you mean you don’t want a compiler with type-in-type, or that you don’t want to take it for granted?

Also, I thought the TypeInType extension itself was deprecated.

#16

This is great. This is what I was hoping actually. I hope that the GHC committee accepts that merging extensions into the language is overall a good thing. The negatives are largely idealism based on no-longer relevant competition (if someone writes a competing Haskell implementation today - 90% of the time they would base that implementation on GHC).

When GHC2021 was written, this decision was left to the GHC committee: which extensions are too useful to not be defaults?

Is it reasonable to ask the GHC committee a natural follow-on question: which extensions are too core to GHC to not be in the language itself (such that you cannot turn them off)?

I am asking “can” we remove extensions. I think it is obvious that we would want remove extensions as the language matures. If every Haskell project uses an extension, that feature is part of the language - and removing it would be salient and practical.

Perhaps I have to ask an even more fundamental question: do we want to remove extensions? I thought the answer was an obvious yes, because a more coherent and simpler language is preferable. But perhaps you disagree?

What it gives me is a list of 50 extensions that may or not work together. If I teach a student Haskell today and explain Functor, I would say “you can derive Functor in Haskell”, and would never consider turning on an extension. If I had to, and they asked “oh that seems useful, why is it behind an extension?” I would say, “I have literally no idea - it’s used universally and causes no problems to users who don’t want to derive Functor”.

If GHC removes some extensions, then the list gets to be 40 extensions - an improvement.

Removing the extensions is not difficult - removing some if-statements and reducing DynFlags would simplify GHC. The challenge is the discussion that decides whether to move forward. If this is a waste of time for the GHC team, I welcome them to tell me “this is an inefficient road to go down”.

Well seeing as the HF just hired a full-time GHC infra engineer, I think it’s fair to say HF is more concerned with GHC than “Haskell”… I have never once seen any compiler other than GHC mentioned in HF materials.

1 Like
#17

Hmm…

…then it would probably be useful for the language standard (currently the Haskell Report) to reflect those new language features. Having an relevant language standard doesn’t only benefit would-be implementors…

Considering what happened to Haskell 2020, taking a more Rust-like approach to evolving Haskell is an appealing alternative. But even Rust has its “editions” as part of its goal of “stability without stagnation”. I would also assume that those who propose and/or request each new set of Rust features also (in some way) help out with updating the “Rust book”, so that it’s relevant for students now and in the future.

I’m curious: does anyone know how well the Rust CI-style approach works for removing language features? It’s probably due to laziness or disinterest on my part, but I can only recall it being used to add new features to Rust. This is relevant to Haskell, as one language feature - (n+k) patterns - has been removed from the current most-recent [2010] standard: how would that have worked using Rust’s approach?

1 Like
#18

The docos say " The extension TypeInType is now deprecated: its sole effect is to switch on PolyKinds (and hence KindSignatures) and DataKinds."

So I’m saying I don’t want those three extensions to be on by default. Behind that, I’d prefer to be able to get Haskell 98 kind-level semantics: Kinds to be distinct from Types.

#19

You’re going to set off another bunch of complaints about breaking code: what happens to all those programs that currently set an Extension? Does GHC tolerate that flag even though it does nothing? Issue a warning? Do we want a pragma to suppress issuing that warning? Because somebody’s bound to complain there’s too many warnings. And of course manage the breaking changes through the three release cycles. Aren’t there more important things for the GHC team to get on with?

And GHC will need to continue to support Haskell2010 and Haskell98 extensions – which will become contractions(?) Suppose I want Haskell2010 + FlexibleInstances?

2 Likes
#20

I see you raisea good reason to say why we shouldn’t remove extensions: it would break old code. But I do think that we would ideally be in a place where such a change is easy to execute. For example, a pre-processor that removes:

  1. Mentions of removed extensions from .cabal files
  2. Mentions of removed extensions from Haskell source files

Anyway - these are details. I think definitely you raise a good reason not to make extensions part of the core language.

And GHC will need to continue to support Haskell2010 and Haskell98 extensions – which will become contractions(?) Suppose I want Haskell2010 + FlexibleInstances ?

I don’t see how what you’re saying conflicts with removing extensions? If the extension weren’t removed, you would just use the extension as you do today.

Unless I’m wrong btw, TypeInType is now permanently part of GHC (and besides yourself I don’t think I’ve seen anyone complain), so there is certainly precedent for merging extensions into the core language.

1 Like
#21

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?

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.

#22

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.

#23

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)

1 Like
#24

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

#25

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

1 Like
#26

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.
1 Like
#27

Which ones are that, in your opinion?

#28

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:

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

#29

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.

#30

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

… 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.)

#31

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.