How did we get from Haskell 98 to Haskell 2010?

#1

Every few months, there’s conversation around when the next language standard is going to come out, and every few months there are replies about how we’re never getting a new one (GHC2021 is great, BTW).

That got me wondering how much work goes into writing a new language standard. Just looking at the Haskell 2010 Language Report, I see it’s 300+ pages!

Maybe all the decades humanity has spent writing new editions of popular books make such a task not so daunting, but as a complete novice, I fail to see how one even begins this journey.

I naively thought I could slowly start converting the standard to something like mdBook or sphinx and then slowly integrate differences implemented in GHC, but now I’m starting to realize how foolish that probably is. This then led me to the title of this post, in hopes that prior art would make even dreaming of such a thing less terrifying.

1 Like
#2

A good question. I dimly recall a committee being part of the process (much like the one which brought Haskell into existence in 1987) - trying the search term:

"Haskell 2010" committee

…finds the Haskell 2010 Report as a matching document:

That’s a reference to the inaugural committee; looking further:

That’s because there was an attempt made at defining a successor to Haskell 2010:

From what I can recall, it was an attempt at a new “single monolithic revision of the language”, and it really “was too large a task” to undertake. That you now have GHC 2021 is a direct consequence of that failure.

Unfortunately, I don’t know where the sources for the Haskell 2010 Report are - I’ve tried looking in the past for them (apparently with no success, otherwise I could be attempting to do something like what you’re contemplating right now).

It’s actually in two parts: one for the language itself, and the other is for the libraries. Focus on the part which interests you the most. I think these are the sources:

Therein lies the other problem: which set of differences?

Not all GHC extensions are compatible with each other, and adding new ones is now something of a sport…

2 Likes
#3

You’ll see the 2010 Report is very little different vs '98. (The differences are in blue in the pdf.)

A lot of folk were/are unhappy about that: a lot of effort went into discussions/there were a lot of extensions widely used since the '98 Standard.

BTW GHC 2021 is not a language Standard, but a default set of extensions chosen for one particular compiler.

I think Haskell has given up trying to have a formal Standard. GHC is a de facto Standard.

#4

My thought was to see what would happen if I folded what’s defined in the GHC2021 extension directly into the standard.

If what was different between Haskell98 and Haskell2010 truly wasn’t that large, maybe it wouldn’t be so hard.

The other thing I considered (in addition to or instead of the above) was to try and track down where GHC intentionally diverges from the standard and update those portions of the standard. I vaguely remember hearing that GHC and the standard differ with respect to how whitespace ought to be parsed, for instance.

I wonder how easy it is to treat prose like code with respect to commiting revisions? That is, does git baulk at the idea of merging separate commits, each of which adds text relating to a specific extension (which would presumably no longer be an extension)? Perhaps there are similar tools better tailored to technical writing that help minimize conflicts?

#5

“Haskell is a language designed by committee” (or words to that effect) it says in the Report. You copy-pasting something into a text is not a committee process, does not define any Standard, doesn’t turn an extension into a non-extension.

GHC 2021 is merely a set of defaults. Not everybody uses it in all of their code. Some (like me) don’t use it at all/prefer to enable specific extensions only when needed/actively dislike some of the GHC 2021 extensions. This is why the GHC 2020 Committee ground to a halt.

OTOH many switch on a whole bunch of extensions beyond GHC 2021.

Who would be the target audience for such a copy-paste job?

1 Like
#6

By the way, the “Haskell 2020 committee” was called the Haskell Prime (or Haskell’) 2020 committee. There are a bunch of remains scattered over the internet:

Especially the last thread in that mailing list might be of interest to you:

3 Likes
#7

Simply to remove barriers. If debate is preventing people from agreeing to write anything down, then perhaps having everything written down already reduces coming to consensus (about one aspect of the report anyway), to an exercise of deciding what to keep?

Deciding what to make for dinner and agreeing on who is responsible for cooking it is harder than deciding whether you want to eat what’s in front of you or not.

<Never mind, it doesn’t matter>

1 Like
#8

Thanks. I recall some of those conversations now that you’ve resurfaced those.

#9

@AntC2 I find your language about “copy-paste job” unwelcoming and disrespectful to efforts of others.

6 Likes
#10

Regarding those old sources for the Haskell 2010 Report: the search term used was "Haskell 2010" latex sources.

If you choose to work on your own private draft/prototype version, do try to work with the Tex documents directly - Tex for publishing book and papers is like HTML for publishing to the Web: it’s ubiquitous. If you look, there are probably Tex convertors for almost every other format, including mdBook and sphinx.

Can a mod delete my account please?
#11

Thanks good find! In particular Cale’s first reply to the ‘humble message’ says more eloquently and at greater detail what I was trying to say about the unhelpfulness of producing another document just drawing together existing text: what status does it have wrt the Haskell doco set? It’ll go out of date almost immediately. Who/how to maintain it?

I think you’ve misunderstood me. I didn’t mention efforts of others plural. I was not talking about the Haskell Prime/2020 team, who made great efforts to in effect herd cats. (Or strewth is somebody going to take offence at that description? I apologize and withdraw) They weren’t merely focused on the text; they were trying to make decisions/draw a consensus.

O.P. seemed to be under the impression the Haskell community lacked resources or the will to produce a document merging the 2010 Language report with later ‘de facto’ GHC material, especially GHC2021 extensions specs.

The comment “no longer be an extension” had me baffled. I could only interpret it to mean O.P. intended the resulting doco to legislate GHC2021 into effect as a new Language report.

#12

I understood you fairly well, and I meant specifically your treatment of the O. P.

Which is a correct impression.

Which does not explain harshness and rudeness of your response to an offer of free labor on a community project.

3 Likes
#14

@Delete_me idk if u still arround, but for context, sandy made a writeup on the status of haskell 2020, which at some point was an effort underway.

You’ve my support if you want to drive an effort of a new standard. I can’t lead this however. The task is to big for me to lead myself as I’ve other obligations, but I can help out here and there.

#15

Er folks, recent remarks here are getting rather ad hominem-y.

I hope we’ve all enough experience of complex software projects to know there’s no such thing as “free labor”. Especially not from someone who introduces themselves as “a complete novice”. (I took that to be wrt Haskell, not wrt software dev in general or doco tools.) It would be demotivating for them and probably not arrive at the desired result without continual liaison – from who?

Nor is there a shortage of folk who can write/edit text about Haskell. It’s going on all over: Stackoverflow, reddit, Discourse, blogs, mailing lists … I’ve even volunteered material to the User Guide myself. That was free from me but not for the dev. team. And didn’t get all the way through the release process until more than a year after I first sent it in.

Producing a new Standard is chiefly not about managing the text.

The several initial replies (including from me) to the O.P. tried to warn of this. On reading back, perhaps they were too subtle/assumed too much background knowledge. I do wish that thread “Humble message” had appeared earlier. Cale explains the challenges in detail. And the danger it’ll be wasted effort.

So when O.P. Replied with

What did yous think would happen with that updated text? Why did Haskell have a Prime/2020 Committee if it only needed a bit of updating to make something (what?) “presumably no longer be an extension”?

O.P.'s reply seemed to me not listening and not thinking through objectives. So I felt it needed saying more clearly: the exercise is not about managing text, not the mechanics of version control, not merely a lack of willing hands. I’m not sure more recent remarks from others are grokking this. So:

My direct language didn’t get the message across. I failed. Furthermore, my being against the suggested actions was taken as being against the suggester. Where in my words am I doing other than ‘playing the ball’?

#16

A new standard might not be very useful, since it will be constantly out of sync with the GHC steering committee, wouldn’t it? Unless there will be an efficient process of amending/revising the standard and doing so that nothing gets into GHC mainline until it’s in the standard. That will also require more thought about how to ship experimental compilers or how to make GHC standard conform via flags.

Don’t see that happening, so the standard is nothing but a formal milestone, more carefully evaluated than GHCXXXX.

1 Like
#17

Indeed, as Cale pointed out. O.P. made an important observation:

Going from GHC, the User Guide does get you to the applicable point in the standard. But reading the standard (like a novel? does anybody do that?) it’s hard work connecting to where in GHC docos.

Then (if anybody is still listening) a less bit-rottable resource might be a parallel commentary following the Report sequence: section p.q in the Report is amended [**] by section x.y.z in the User Guide – including the GHC2021 cross-refs. With links only, and just enough words to give context – the bulk of the words stay at the links.

This should be nicely interactive and fit into the GHC wiki structure. But I emphasize first contact the owners/maintainers of the wiki for their counsel. (They were a lot less exacting than the User Guide edit control when I added some material.)

[**] Less contentious phrasing there might ‘is implemented as’ or ‘is interpreted in context of GHC as’.

#18

Documenting a production language is indeed daunting. (Standardizing implies documenting.) ISO C11 is 600+ pages (including libraries again), for comparison.

In fact Haskell got away with being half the size becasue, only because, it handwaves away 90% of static semantics with “oh it’s just Hindley-Milner”, and 90% of dynamic semantics with “oh it’s just lambda calculus”. Notice that C spells out both painstakingly (not “oh just like Algol 60 with these changes”).

Then again my comparison can backfire because you can point at SML97 which needs only 130+ pages. (But it doesn’t include the standard library.)

I happen to be of the unusual and unpopular opinion that not documenting the baseline type system is what’s blocking meaningful standardization of any of GHC’s type-oriented extensions.

(I know of Mark Jone’s Typing Haskell in Haskell, but we need to add it to the Haskell Report for real, and probably in judgment form rather than in “Defining Haskell in Haskell” form LOL.)

3 Likes