Announcing the new Haskell Prime process, and Haskell 2010

[Simon Marlow]

On 07/07/2009 16:40, Claus Reinke wrote:
>> At last year's Haskell Symposium, it was announced that we would
>> change the Haskell Prime process to make it less monolithic. ..
>> In the coming weeks we'll be refining proposals in preparation for
>> Haskell 2010.
>
> Given the incremental nature of the new standards, would it be
> useful to switch back to version numbers, eg "Haskell 2.0.0 (2010)"
> instead of "Haskell 2010"? Otherwise, we'll end up with half a
> dozen more or less current Haskells related by no obvious means.
> "Haskell'98" was chosen because it projected more permanence
> than the Haskell 1.x line of Haskell revisions that came before it.

The relationship between the versions will be quite clear: each revision 
will be specified by a set of deltas to the previous one.  I think the 
year-based naming scheme is fine, especially since we're planning to 
produce annual revisions.

An important question though is what we should call the major versions. 
  There it will probably make sense to use "Haskell 2", "Haskell 3", and 
so on.  I imagine the first major version won't be for a few years, though.

> Having API instead of date encoded in the name would support
> deprecations, breaking changes, or additions as well as make it clear
> whether a new year's version does break anything or not.
>
> Btw, once upon a time, there was a discussion about an even
> more modular approach, standardising language extensions
> without saying which extensions made up a standard language.
> That would give support to the status quo, where people want
> to use, say, Haskell'98+FFI+Hierarchical Modules+MPTC+..
>
> In other words, existing language extensions (LANGUAGE
> pragmas) ought to be standardized (currently, they mean different
> things in different implementations), independent of whether
> or not the committee decides to group them into a Haskell X.

What you're suggesting is not incompatible with Haskell'.  In Haskell', 
each change to the language will be independently specified, as an 
addendum, before being accepted as part of the language.

So a side-effect of the standardisation process is a set of addenda, 
that you could mix and match.  GHC will still support one flag per 
extension, where it makes sense (there's not much point making a flag 
for fixes and trivial changes).  So in GHC, {-# LANGUAGE Haskell2010 #-} 
could be expanded to the set of extensions in Haskell 2010, and will 
probably be implemented that way.

Cheers,
	Simon