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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
