I don’t know if you’re aware but that’s the burden of every standardised language.
1 Like
So we could remove some of the burden for, say, Haskell 10.X no? I’m not seeing how “it’s a common burden” is a reason to not relieve some of that burden.
We could, but you think that you can escape the process of producing a new standard because you are only aware of GHC. However, even if GHC is the most prominent (and relevant), it’s not alone in this space.
I too would like to see some extensions part of the language, but this needs a new language. 
3 Likes
Out of curiosity, are there other implementations of Haskell that are industrial strength? I am aware of:
- eta (sadly defunct), diverged heavily from GHC
- Frege which is happily not dead, but definitely niche (do you know who maintains intellij-frege). From the readme, appears to match Haskell 98-or-so.
- Hugs - appears to have no presence
- Mu - which is a dialect, and not public; diverged heavily from GHC
- Asterius/GHCJS - merging into GHC tree
I often see this idea that Haskell is not GHC - but on the other hand, this “non-GHC Haskell” doesn’t appear to exist - who maintains “Haskell”, how can one make proposed language changes? Also isn’t GHC already not “Haskell”: is TypeInType “Haskell”, are the many recently-accepted proposals (type-term namespaces; existentials) “Haskell”?
Implementations of “Haskell” are one of (1) subsets of GHC (2) strictly divergent from GHC (3) merging into GHC; so why is GHC faithful to this imaginary spec.
Plus, the Haskell report is pretty much a snapshot of GHC back in 1998 anyway no? Especially since it was written by SPJ and Simon Marlowe.
1 Like
so why is GHC faithful to this imaginary spec.
Because the people in charge of making such decisions haven’t wrapped their mind around this yet.
Yes, as things stand, Haskell is, in its vast majority, GHC. But the idea is to leave some space for other contenders in the space. And without a standard it’s very difficult to offer alternative implementations.
3 Likes
Ah, the joys of a single [mainstream]-implementation language: would this topic have even been brought up if there was a second and comparable Haskell implementation…
…a very salient qualification. I believe the main issue with making a language extension permanent is the potential conflict with other such extensions - at the risk of being repetitive:
- if there are N extensions, then there are at least 2N combinations of those extensions;
- not all of those combinations work in GHC.
Just because you’ve been using your favourite set of extensions for years doesn’t mean they will automatically qualify for permanent inclusion - perhaps the best option now is for some related extensions to somehow be merged together. As for another GHC2021-style compendium e.g. GHC2024…finding another sufficiently-large-and-useful combination of extensions that don’t cause conflicts elsewhere will only increase in difficulty.
…or a new language version in which they can be stabilised - the HF Stability Working Group might be able to provide some guidance here (if they have time to spare).
Unless I’m badly mistaken, I thought that was now the purview of the HF.
…as the current effort to port Rust to GCC clearly shows. In contrast, Prolog has its own ISO standard (parts 1 and 2) and several mature implementations.
Currently there are two relatively well-known non-strict typed languages: Miranda(R) and Haskell; both now being single-implementation languages and having small user bases (Miranda(R) in education, Haskell tending more towards production) - is that a coincidence?
In an alternate reality where non-strict languages are in the majority, not having a language standard may not be such a hindrance. But in this reality, being non-strict is hard work, which must surely make the task of building another implementation for either language even more difficult in the absence of well-specified language standards.
1 Like
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?
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
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
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.
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
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
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.
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
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:
- Mentions of removed extensions from .cabal files
- 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
Haskell2010andHaskell98extensions – which will become contractions(?) Suppose I wantHaskell2010+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
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.
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.
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
- 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.
You know… I meant the extensions without which it is impossible to code.
1 Like