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