Re: Announcing the new Haskell Prime process, and Haskell 2010
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
Re: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010
On 07/07/2009 20:17, Simon Peyton-Jones wrote: | There are a couple sensible removals here. Do we also want to get rid | of the useless class contexts on data-declarations? (that look like | data Ord a = Set a = Set ...) Yes! Yes! Kill them. (In GHC's source code these contexts are consistently called stupid_theta.) This is listed as Remove class context on data definitions in the list of proposals. It doesn't have an owner or a wiki page yet. Any volunteers? Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
marlowsd: At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. Since then, everyone has been busy using Haskell (or implementing it), and we haven't made much progress on the standardisation side of things. Well, with ICFP and the Haskell Symposium approaching we felt it was time to get the new process moving and hopefully produce a language revision this year. Tom Lokhorst suggests[1] Haskell'10 -- Don [1] http://twitter.com/tomlokhorst/statuses/2539313506 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Announcing the new Haskell Prime process, and Haskell 2010
Hello Don, Thursday, July 9, 2009, 1:44:28 AM, you wrote: Tom Lokhorst suggests[1] Haskell'10 now i understand - Haskell committee was just skipping those unbeautiful one-digit years :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
Don Stewart wrote: Tom Lokhorst suggests[1] Haskell'10 [1] http://twitter.com/tomlokhorst/statuses/2539313506 How pessimistic. Some people expect Haskell and/or Haskell' not to be around anymore in 2110? Wolfram ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Announcing the new Haskell Prime process, and Haskell 2010
Hello kahl, Thursday, July 9, 2009, 2:43:01 AM, you wrote: Haskell'10 Some people expect Haskell and/or Haskell' not to be around anymore in 2110? it would be Haskell10 :) ability to accurately count apostrophes is one of the prerequisites to learn Haskell :D -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Announcing the new Haskell Prime process, and Haskell 2010
At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. Since then, everyone has been busy using Haskell (or implementing it), and we haven't made much progress on the standardisation side of things. Well, with ICFP and the Haskell Symposium approaching we felt it was time to get the new process moving and hopefully produce a language revision this year. I've updated the Haskell' wiki with the new information; in particular the process is documented here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process We're aiming to announce the list of accepted proposals at the Haskell Symposium this year. However, owing to the short timescale, the list is going to be correspondingly short, and limited to extensions which are either already fully specified (i.e. the FFI) or are small and well-understood. The following list is very provisional; we'll be making the final decisions next month. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be complete (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as old. The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the under discussion state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
On Tue, Jul 7, 2009 at 10:27 AM, Bulat Ziganshinbulat.zigans...@gmail.com wrote: Hello Simon, Tuesday, July 7, 2009, 6:04:46 PM, you wrote: i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements This is not a complete list of what would be in a next major Haskell standard (what we've all been calling Haskell'). The problem of producing a new major standard in one step has proven intractable to date. Instead, given the state of completed addenda beyond Haskell 98, this is a provisional list of features that the Haskell' committee thinks would be feasible to include in a 2010 revision of the Haskell standard. We're *very* open to considering features not on this list (consider the results of the various straw polls, for example), but to be eligible for consideration for Haskell 2010 any additional proposals would need a completed, high-quality addendum by August, so the clock is ticking... - Ravi ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
Hello Simon, Tuesday, July 7, 2009, 6:04:46 PM, you wrote: i can't understand. does this list supposed to be full list of changes in haskell'? it seems to include mainly supplementary syntax changes while even Rank2Types are not here, the same for assoc. types, GADTs and other fundamental type system improvements and btw - from my user's POV, we can just start with common GHC Hugs subset, remove a few features, add a few GHC-specific features and will become close to what should be named next Haskell standard, standard de-facto of Haskell used in last years. why so much time spent on this process.. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be complete (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as old. The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the under discussion state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
i can't understand. does this list supposed to be full list of changes in haskell'? this is a provisional list of features that the Haskell' committee thinks would be feasible to include in a 2010 revision of the Haskell standard. And just to add, the new standardisation process means that there will also be a Haskell 2011, Haskell 2012, etc. If a feature is not completely specified in time for one standard, then it will not need to wait long until it can be accepted in the next one. Eventually, the process might give us a standard that is stable and unchanging, but right now, we need to take it small pieces. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announcing the new Haskell Prime process, and Haskell 2010
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. 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. Claus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010
Simon Marlow wrote: Remove n+k patterns remove FixityResolution from the context-free grammar There are a couple sensible removals here. Do we also want to get rid of the useless class contexts on data-declarations? (that look like data Ord a = Set a = Set ...) -Isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010
Isaac Dupree wrote: Simon Marlow wrote: Remove n+k patterns oh also -- anything like this that we remove should get a LANGUAGE flag to go along with it. I don't see NPlusKPatterns in Language.Haskell.Extension yet :-) -Isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010
| There are a couple sensible removals here. Do we also want to get rid | of the useless class contexts on data-declarations? (that look like | data Ord a = Set a = Set ...) Yes! Yes! Kill them. (In GHC's source code these contexts are consistently called stupid_theta.) Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
