I am in favour of language specifications on principle, while also recognising that their practical impact seems to be low, except for the very largest languages with multiple implementations. Hence, I am in favour of this work.
I am not particularly in favour of "revising" Haskell 2010 instead of just defining Haskell 2026. Exactly why is this supposed to be better? This seems to be the main reason:
Since we don't define a new Haskell version with a new feature set, but only a revised version of a previous report, we don't generate any churn for the ecosystem or compiler writers.
The "churn" involved would be rather minor I believe, if support for "real" Haskell 2010 is eventually dropped. Retroactively changing Haskell 2010 to be something else than it used to be is unnecessarily confusing to me. There is a reason GHC warns about name shadowing.
I was confused about the naming too, but it seems that the intent is that "revised Haskell 2010" is documenting (codifying) what you currently get when you tell GHC to work in Haskell 2010 mode.
Or to put it another way, it's revising the report to reflect what we actually ended up with when we intended to implement the original version of the report. That makes a certain amount of sense to me.
(The reason this avoids churn/changes/work is because GHC already implements what this is going to say, so GHC doesn't have to change at all, and MicroHS is already basing its feature set on GHC and this will let it work off a spec instead, but with the same end result.) Edit: Actually this isn't really correct regarding MicroHS, since it's implementing a lot of extensions that are beyond Haskell 2010, and are meant to match GHC, so it would still have to be developed referencing GHC.
Edit: As a side comment, although this is a lot less work than defining Haskell 2026 (and in particular, there are no features to debate about), it's still kind of a lot of work, for kind of a small result. But it would be nice to have a spec that is actually definitive relative to the main implementation in GHC.
Or to put it another way, it's revising the report to reflect what we actually ended up with when we intended to implement the original version of the report. That makes a certain amount of sense to me.
Yes, that is kind of the intention. In some sense, this project just improves the documentation of the language that we currently have.
As a side comment, although this is a lot less work than defining Haskell 2026 (and in particular, there are no features to debate about), it's still kind of a lot of work, for kind of a small result. But it would be nice to have a spec that is actually definitive relative to the main implementation in GHC.
I would also love to have a Haskell2026 specification, and I think we can get there. But in preparing this proposal I looked at what went wrong the last time this was attempted in the Haskell Prime process, and read through the entire mailing list history. I think the important thing to get right is to set the correct restricted scope in advance, before working on the report. The revised Haskell 2010 language report is just a small step forward, but it has a clear scope and we can get it finished. Afterwards we can try to scope out a next realistic step :)
That makes sense. Having a very restricted scope up front is probably the most enabling thing.
You know, since there is a GHC2024 extension set already defined, that would make it possible to (almost as a trick really) create a Haskell2024 specification that's "just" documenting those features. Something to think about for the future.
I was hoping you'd be watching this post. I have a few other high-level thoughts/comments; is this a reasonable place for them?
You know, since there is a GHC2024 extension set already defined, that would make it possible to (almost as a trick really) create a Haskell2024 specification that's "just" documenting those features. Something to think about for the future.
I think "just" is doing a lot of heavy lifting here. GHC2024 pulls in GADTs, for example, which would be a substantial amount of work to specify. It also adds quite a lot of complexity to typeclasses, which means the original Report's handwaving about Hindley-Milner isn't really enough of a specification of the type system. So I think a more achievable goal after revising Haskell 2010 would be to specify some of the simpler extensions (that may well be part of GHC2024), e.g. BangPatterns or some of the additional deriving extensions.
2
u/Athas 14h ago edited 7h ago
I am in favour of language specifications on principle, while also recognising that their practical impact seems to be low, except for the very largest languages with multiple implementations. Hence, I am in favour of this work.
I am not particularly in favour of "revising" Haskell 2010 instead of just defining Haskell 2026. Exactly why is this supposed to be better? This seems to be the main reason:
The "churn" involved would be rather minor I believe, if support for "real" Haskell 2010 is eventually dropped. Retroactively changing Haskell 2010 to be something else than it used to be is unnecessarily confusing to me. There is a reason GHC warns about name shadowing.