Re: Announce: ~Haskell 2011
On Fri, Jan 07, 2011 at 06:39:11PM +, Malcolm Wallace wrote: As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; What is the status of this? Should the datatype contexts be removed from the base package? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announce: ~Haskell 2011
On Fri, Jan 07, 2011 at 06:39:11PM +, Malcolm Wallace wrote: (b) this delta will be applied to the 2010 Report to form a new baseline; Did this happen? If so, where is it? I only found: http://darcs.haskell.org/haskell-prime-report/ which hasn't had a patch since Jul 21 2009, and: http://darcs.haskell.org/haskell98-report/ http://darcs.haskell.org/haskell2010-report/ which are for older versions of the standard. (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts Shouldn't http://hackage.haskell.org/trac/haskell-prime/ticket/139 be state accepted and closed now, then? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Announce: ~Haskell 2011
(a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts The Trac-Wiki says: What removing the datatype contexts from a source file will do is make some previously illegal programs legal. What is an example? As on the wiki, data Eq a = Foo a = Constr a getVal :: Foo a - a getVal (Constr x) = x would previously have been rejected. Once the compiler forces the user to remove the Eq a = context on the datatype, the rest of the program will be accepted. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announce: ~Haskell 2011
So, I wish to declare open season on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Did anybody ever do a count on Hackage which language extensions are used the most? -- Sjoerd Visscher ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Announce: ~Haskell 2011
On 7 Jan 2011, at 22:25, Ian Lynagh wrote: Have you considered deciding about individual proposals as and when they are completed, rather than making a decision about all proposals each September? This could also avoid merge-conflicts between the report deltas for proposals that touch the same bit of the report. I can see advantages and disadvantages of both approaches - incremental decisions vs a single time-limited big decision. I think it all depends on the engagement of the community. If there is clear consensus from the community on a particular proposal, I can imagine the committee incrementally accepting it. If consensus is not clear, I think a decision is likely to be deferred until voting-time. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Announce: ~Haskell 2011
The Haskell Language committee has had a quiet year. Following the announcement of Haskell 2010 in Nov 2009 [1], and the publication of the 2010 Report in July 2010 [2], we found a distinct lack of complete new proposals to decide upon. As a result, the committee has made the following decisions: (a) we wish to accept the NoDatatypeContexts proposal http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts (b) this delta will be applied to the 2010 Report to form a new baseline; (c) we will _not_ issue a new language standard called 2011; (d) we intend to issue a new language standard in 2012; (e) the committee will continue for another year without new nominations. However, let me make it clear that the apparent lull in committee activity does not mean there are no active proposals being made. On the contrary, proposals for language features (and removals) are made by the community at large (that's you) - the committee's main role is not to make proposals, but to decide which to accept. And there have in fact been a large number of proposals, but very few have made it all the way to the stage of producing a language report delta that could be accepted (or modified) by the committee. So, I wish to declare open season on proposals for the 2012 standard. If there is a language feature you care about, please do take an hour or two to review the details on our wiki [3], search for older discussions on the mailing lists, and draft the Report changes you think would be necessary. I'm looking forward to a more active and exciting collection of potential language changes for 2012, but it will only happen if you get involved. Regards, Malcolm (Haskell 2011 committee chair) [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html [2] http://www.haskell.org/pipermail/haskell/2010-July/022189.html [3] http://hackage.haskell.org/trac/haskell-prime/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Haskell 2011?
Hi all, I haven't heard anything about Haskell 2011 since http://www.haskell.org/pipermail/haskell-prime/2010-August/003263.html Can someone let me know what's happening please? Will there be a Haskell 2011? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: preparing for Haskell 2011
On Mon, Aug 09, 2010 at 04:25:18PM +0100, Malcolm Wallace wrote: Can I therefore encourage any people who have made proposals, either informally on mailing lists, or formally in the Haskell-prime ticket system, to consider what they need to do to bring those proposals to a state where the committee can vote on them. I believe http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts is ready; please let me know if there's something else I need to do. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
preparing for Haskell 2011
Dear all, Although the Haskell 2010 Language Report has only been published recently, it will soon be time for the Committee to make decisions on the next version, Haskell 2011. I am aiming for the committee to make decisions around the end of Sept or beginning of October 2010. Can I therefore encourage any people who have made proposals, either informally on mailing lists, or formally in the Haskell-prime ticket system, to consider what they need to do to bring those proposals to a state where the committee can vote on them. Perhaps you have not made such a proposal yourself, but are very keen that someone else's proposal be adopted. Work with the proposer to polish it! Here is what you need to know about the proposal process: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Please note especially that the key requirement that will bring your proposal to the attention of the committee for a decision is the Report delta, which describes the changes with exact precision. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
Anthony Clayden
anthony_clay...@clear.net.nz
writes:
(I know how you're always looking for things to take out of
Haskell ...)
I can see the ugliness of having a name with two
incompatible types (especially in the same scope).
Granted.
After all, the program text declares { f :: Int }, and in
all uses of the field label apart from selecting, it _is_ an Int.
It's not; it's shorthand for something else (a bare f in a
programme doesn't get you an Int -- which one would it be?). One
of the nice things about Haskell is that if you know the name of
something and the something has a type, then you know something
about all the possible values it can have. In current Haskell, f
here isn't a name in that sense, which is a big pity (you can't
pass a field label as an argument to a function, for example).
Where does this function thing come from?
It comes (as you imply) from it's use as a field selector. I'd
say that (and field update) were its primary uses. It would be
far better to make field labels proper first-class entities that
have a translation into lambda calculus (or System F as you
will).
I would much rather see field labels having their own type,
so that
data F t = F {f:: H t}
declares the type F, the constructor F and a name
f:: Selector (F t) (H t)
the language definition needn't make whatever is inside Selector
directly visible to the programmer, but we can think of it as
secretly being a pair of functions
((F t - H t), (H t - F t - F t))
Now f x would be an overloaded meaning of application¹. And
r{f=g} would be shorthand for (magic-snd f g r), where magic-snd
is just snd made suitable for application to Selector. (Frankly,
I'd rather lose the r{f=g} syntax and provide an operator that
accesses the second part of f so that it can be applied as a
function, eg (f←g) r. This (f←g) would then also be a first
class function.)
Doing it this way would get rid of the peculiar multiple type
issue, make it completely clear what field labels translate to
and give us field labels as proper first class entities.
[1] as it currently is, and I'm not suggesting allowing general
overloading of application, but at least this way we'd know what
f was
--
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
Simon Marlow wrote:
While I agree with these points, I was converted to record punning
(actually record wildcards) when I rewrote the GHC IO library. Handle
is a record with 12 or so fields, and there are literally dozens of
functions that start like this:
flushWriteBuffer :: Handle - IO ()
flushWriteBuffer Handle{..} = do
if I had to write out the field names I use each time, and even worse,
think up names to bind to each of them, it would be hideous.
What about using field names as functions?
flushWriteBuffer h@(Handle {}) = do
... buffer h ...
Of course, you always have to drag h around.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
Hello,
In order to keep the discussion structured I have created two tickets
in the haskell-prime trac system
(http://hackage.haskell.org/trac/haskell-prime):
* Proposal 1: Add pre-Haskell'98 style punning and record
disambiguation (ticket #136)
* Proposal 2: Add record-wildcards (ticket #137)
I decided to split the two into separate tickets because, at least in
my mind, there are different things that we might discuss about the
two, and also they make sense independent of each other (although
record wildcards without punning might be a bit weird :-).
I think that both proposals are worth considering for Haskell 2011
because there are situations where they can significantly improve the
readability of code involving record manipulation. I disagree with
the stylistic issues that were brought up in the discussion because I
do not believe that variable shadowing should be avoided at all
costs: at least for me, avoiding shadowing is a means to an end
rather then an end in itself. In the case of record puns, I think
that the clarity of the notation far surpasses any confusion that
might be introduced by the shadowing. Furthermore, as other
participants in the discussion pointed out, the proposed features are
orthogonal to the rest of the language, so their use is entirely
optional.
-Iavor
On Fri, Feb 26, 2010 at 2:59 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Simon Marlow wrote:
While I agree with these points, I was converted to record punning
(actually record wildcards) when I rewrote the GHC IO library. Handle
is a record with 12 or so fields, and there are literally dozens of
functions that start like this:
flushWriteBuffer :: Handle - IO ()
flushWriteBuffer Handle{..} = do
if I had to write out the field names I use each time, and even worse,
think up names to bind to each of them, it would be hideous.
What about using field names as functions?
flushWriteBuffer h@(Handle {}) = do
... buffer h ...
Of course, you always have to drag h around.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
RE: PROPOSAL: Include record puns in Haskell 2011
| we implicitly get
| f :: T - Int
| which punning shadows with
| f :: Int
| whereas I generally avoid shadowing completely.
|
| I agree with Ian.
|
| I tend to agree.
I originally had field puns in GHC, and then took them out when Haskell 98
removed them, after a discussion very like this one. I put them back in
because some people really wanted them.
Actually GHC has three separate extensions to do with named fields:
field disambiguation (Section 7.3.14)
field puns (Section 7.3.15)
field wildcards (Section 7.3.16)
Look here
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields
Opinions differ. I'm rather with John: let the programmer choose, rather than
enforcing a style in the language. For punning, the programmer can certainly
choose on a case by case basis. If you use Haskell 98's existing syntax, there
is no change to the semantics if you switch on field puns:
data T = C { f :: Int }
foo (C {f = x}) = ... -- No punning
bar (C {f}) = ... -- Punning
It would help this discussion if someone created a ticket to explain the actual
proposal, so that we are all discussing the same thing.
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
Isaac Dupree m...@... writes:
On 02/24/10 13:40, Martijn van Steenbergen wrote:
Ian Lynagh wrote:
I have a feeling I'm in the minority, but I find record punning an ugly
feature.
Given
data T = C { f :: Int }
we implicitly get
f :: T - Int
which punning shadows with
f :: Int
whereas I generally avoid shadowing completely.
I agree with Ian.
I tend to agree.
snip
-Isaac
(I know how you're always looking for things to take out of
Haskell ...)
I can see the ugliness of having a name with two
incompatible types (especially in the same scope).
I wonder: if a programmer from Mars landed into Haskell a la
GHC 2010 (that is, unburdened by history back to v1.3),
wouldn't it be the scare-quotes 'implicit' field selector
that seems the odd man out?
After all, the program text declares { f :: Int }, and in
all uses of the field label apart from selecting, it _is_ an Int.
Where does this function thing come from?
By the way, it seems you can arrive at the same
level of confusion like this (declared in a distinct scope):
f (C { f }) = f-- f :: T - Int
- Anthony
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
(I know how you're always looking for things to take out of Haskell ...) I can see the ugliness of having a name with two incompatible types (especially in the same scope). That's a good point, but even if not totally logical I think the automatic Rec - X function is more important than the X meaning. Functions are more resistant to change (for instance, I changed from String to Data.Text but could keep the old recString as a function when the field named changed), so while I think the sugar to bring names into scope is handy, I think functional access should be encouraged as the main way to do it. The whole tension between syntactic convenience of pattern matching and the flexibility of function accessors in the face of change is kind of unfortunate. It mirrors the OO dilemma of x.y vs. x.y(), which some OO languages do away with altogether. So I'd want to go the other way by making functional access and update more convenient and prominent rather than syntactical. Maybe we could have a little extension of view patterns where f (field -) = y is transformed to f (field - field) = y. It's still a shadow, but at least now it works with any function. It might be nice to do the same with update functions, but those aren't even generated automatically (anyone got a generics thing that cranks those out?). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
PROPOSAL: Include record puns in Haskell 2011
Hello,
(Malcolm, sorry for the double post, I forgot to CC the list)
I was thinking mostly about the old-time-y punning, where I can
write a label, say theField, and it automatically gets expanded to
theField = theField, in record patterns and record constructing
expressions.
The only corner case that I can remember about this is the interaction
with qualified names, the issue being what happens if a label in a pun
is qualified? I think that in such cases we should just used the
unqualified form for the variable associated with the label. In
patterns, I can't think of any other sensible alternative. In
expressions, I could imaging expanding A.theField to A.theField =
A.theField but it seems that this would almost never be what we want,
while in all the uses I've had A.theField = theField is what was
needed.
I think that this is exactly what GHC implements, at least based on
the following example:
module A where data T = C { f :: Int }
{-# LANGUAGE NamedFieldPuns #-}
module B where
import qualified A
testPattern (A.C { A.f }) = f
testExpr f = A.C { A.f }
I imagine that this is fairly close to what was in Haskell 1.3? As
far as wild-cards are concerned, I don't feel particularly strongly
about them either way (I can see some benefits and some drawbacks) so
I'd be happy to leave them for a separate proposal or add them to this
one, depending on how the rest of the community feels.
-Iavor
On Wed, Feb 24, 2010 at 1:35 AM, Malcolm Wallace
malcolm.wall...@cs.york.ac.uk wrote:
I'd like to propose that we add record punning to Haskell 2011.
Can you be more specific? Do you propose to re-instate punning exactly as
it was specified in Haskell 1.3? Or do you propose in addition some of the
newer extensions that have been recently implemented in ghc (but not other
compilers), such as record wildcards?
Regards,
Malcolm
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
Ian Lynagh wrote:
I have a feeling I'm in the minority, but I find record punning an ugly
feature.
Given
data T = C { f :: Int }
we implicitly get
f :: T - Int
which punning shadows with
f :: Int
whereas I generally avoid shadowing completely.
I agree with Ian.
Groetjes,
Martijn.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Include record puns in Haskell 2011
On 24/02/10 18:23, Ian Lynagh wrote:
On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote:
I'd like to propose that we add record punning to Haskell 2011.
Thoughts, objections, suggestions?
I have a feeling I'm in the minority, but I find record punning an ugly
feature.
Given
data T = C { f :: Int }
we implicitly get
f :: T - Int
which punning shadows with
f :: Int
whereas I generally avoid shadowing completely.
While I agree with these points, I was converted to record punning
(actually record wildcards) when I rewrote the GHC IO library. Handle
is a record with 12 or so fields, and there are literally dozens of
functions that start like this:
flushWriteBuffer :: Handle - IO ()
flushWriteBuffer Handle{..} = do
if I had to write out the field names I use each time, and even worse,
think up names to bind to each of them, it would be hideous.
There are reasons to find this distasteful, yes, but I think the
alternative is much worse.
I'm not proposing record wildcards (yet) *cough* labelled-field
wildcards, but punning is a step in the right direction.
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Nominations for the Haskell 2011 committee
I also put myself forward for next year's committee, although I'm equally happy to stand down and make way for new members. In any case I plan to continue working on proposals for Haskell 2011, perhaps we should be thinking about Concurrency for 2011? There's already a draft of the report text that I wrote for Haskell Prime here: http://hackage.haskell.org/trac/haskell-prime/wiki/Concurrency/DraftReportText Cheers, Simon On 14/12/09 12:34, Simon Marlow wrote: So that the Haskell 2011 cycle can get underway, we are soliciting nominations for new committee members. Since this is the first time we've done this, the procedure is still somewhat unsettled and things may yet change, but the current guidelines are written down here: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In particular, on the makeup of the commitee: The committee should represent each class of stakeholders with roughly equal weight. These classes are * Implementers (compiler/tool writers) * Commercial users * Non-commercial users (e.g. open source) * Academic users (using Haskell in research) * Teachers * Authors In addition, members of the committee should be long-standing users with a deep knowledge of Haskell, and preferably with experience of language design. The committee should contain at least some members with a comprehensive knowledge of the dark corners of the Haskell language design, who can offer perspective and rationale for existing choices and comment on the ramifications of making different choices. To nominate someone (which may be yourself), send a message to haskell-pr...@haskell.org. Please give reasons for your nomination. The current committee will appoint new commitee members and editors starting in the new year, so the deadline for nominations is 31 December 2009. During discussion amongst the current commitee, we realised that the choice of committee should be informed not just by the criteria above, but also by the particular proposals that are expected to be under consideration during this cycle. With that in mind, we plan that following the nominations the current committee will choose a core commitee of up to 10 members, and further members may be appointed during the year based on expertise needed to consider particular proposals. Accordingly, now would be a good time to start discussing which proposals should be considered in the Haskell 2011 timeframe, as that may affect the choice of commitee members. More details on the current Haskell Prime process are here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Nominations for the Haskell 2011 committee
If and when you think the MPTC (Multi-parameter type class) dilemma should be discussed, in particular with respect to our recent work on this problem [1], I would be glad if I can contribute. Best regards, Carlos [1] Carlos Camarão, Rodrigo Ribeiro, Lucília Figueiredo, Cristiano Vasconcellos, SBLP'2009 (13th Brazilian Symp. on Prog. Languages), 2009. Available via www.dcc.ufmg.br/~camarao/CT/solution-to-mptc-dilemma.pdf So that the Haskell 2011 cycle can get underway, we are soliciting nominations for new committee members. Since this is the first time we've done this, the procedure is still somewhat unsettled and things may yet change, but the current guidelines are written down here: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In particular, on the makeup of the commitee: The committee should represent each class of stakeholders with roughly equal weight. These classes are * Implementers (compiler/tool writers) * Commercial users * Non-commercial users (e.g. open source) * Academic users (using Haskell in research) * Teachers * Authors In addition, members of the committee should be long-standing users with a deep knowledge of Haskell, and preferably with experience of language design. The committee should contain at least some members with a comprehensive knowledge of the dark corners of the Haskell language design, who can offer perspective and rationale for existing choices and comment on the ramifications of making different choices. To nominate someone (which may be yourself), send a message to haskell-pr...@haskell.org. Please give reasons for your nomination. The current committee will appoint new commitee members and editors starting in the new year, so the deadline for nominations is 31 December 2009. During discussion amongst the current commitee, we realised that the choice of committee should be informed not just by the criteria above, but also by the particular proposals that are expected to be under consideration during this cycle. With that in mind, we plan that following the nominations the current committee will choose a core commitee of up to 10 members, and further members may be appointed during the year based on expertise needed to consider particular proposals. Accordingly, now would be a good time to start discussing which proposals should be considered in the Haskell 2011 timeframe, as that may affect the choice of commitee members. More details on the current Haskell Prime process are here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Nominations for the Haskell 2011 committee
Hello, I would like to participate in the design of Haskell 2011. I have used Haskell for about 10 years, commercially at Galois Inc, for the last 3. I have a good understanding of all parts of the language and various implementations, and I have a particular interest in its type system and semantics, which is why I think that I would be able to provide valuable input to the committee. -Iavor On Mon, Dec 14, 2009 at 4:34 AM, Simon Marlow marlo...@gmail.com wrote: So that the Haskell 2011 cycle can get underway, we are soliciting nominations for new committee members. Since this is the first time we've done this, the procedure is still somewhat unsettled and things may yet change, but the current guidelines are written down here: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In particular, on the makeup of the commitee: The committee should represent each class of stakeholders with roughly equal weight. These classes are * Implementers (compiler/tool writers) * Commercial users * Non-commercial users (e.g. open source) * Academic users (using Haskell in research) * Teachers * Authors In addition, members of the committee should be long-standing users with a deep knowledge of Haskell, and preferably with experience of language design. The committee should contain at least some members with a comprehensive knowledge of the dark corners of the Haskell language design, who can offer perspective and rationale for existing choices and comment on the ramifications of making different choices. To nominate someone (which may be yourself), send a message to haskell-pr...@haskell.org. Please give reasons for your nomination. The current committee will appoint new commitee members and editors starting in the new year, so the deadline for nominations is 31 December 2009. During discussion amongst the current commitee, we realised that the choice of committee should be informed not just by the criteria above, but also by the particular proposals that are expected to be under consideration during this cycle. With that in mind, we plan that following the nominations the current committee will choose a core commitee of up to 10 members, and further members may be appointed during the year based on expertise needed to consider particular proposals. Accordingly, now would be a good time to start discussing which proposals should be considered in the Haskell 2011 timeframe, as that may affect the choice of commitee members. More details on the current Haskell Prime process are here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
nomination for Haskell 2011
Herewith I propose Atze Dijkstra as a member of the Haskell 2011 committee. Atze is the main architect/implementor of the Utrecht Haskell Compiler (see http://www.cs.uu.nl/wiki/UHC, and last year Haskell Symposium), and has as a result of that a very good insight in the implementation issues involved with new features/extensions/changes. He furthermore co-supervises Arie Middelkoop who is working on the Ruler system, which aims to be a tool for describing (the implementations of) type systems, and Jeroen Fokker who is working on a Grin-based whole- program analysis The compiler itself is currently about 100.000 lines of Haskell. A second release is planned for the beginning of next year, which will contain a completely new garbage collector, a cabal based installation scheme, and the beginning of some global optimisations. I think Atze primarily covers the following categories: Implementors, Academic users, Teachers. If you have any questions I am more than willing to answer them, Doaitse ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Nominations for the Haskell 2011 committee
To nominate someone (which may be yourself), send a message to haskell-prime@haskell.org . Please give reasons for your nomination. I would like to nominate Neil Mitchell for the Haskell Prime committee. He falls into the categories of commercial user, and open-source tool writer. He has been part of the Haskell community for around 5 years, and a very active contributor. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Nominations for the Haskell 2011 committee
So that the Haskell 2011 cycle can get underway, we are soliciting nominations for new committee members. Since this is the first time we've done this, the procedure is still somewhat unsettled and things may yet change, but the current guidelines are written down here: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In particular, on the makeup of the commitee: The committee should represent each class of stakeholders with roughly equal weight. These classes are * Implementers (compiler/tool writers) * Commercial users * Non-commercial users (e.g. open source) * Academic users (using Haskell in research) * Teachers * Authors In addition, members of the committee should be long-standing users with a deep knowledge of Haskell, and preferably with experience of language design. The committee should contain at least some members with a comprehensive knowledge of the dark corners of the Haskell language design, who can offer perspective and rationale for existing choices and comment on the ramifications of making different choices. To nominate someone (which may be yourself), send a message to haskell-pr...@haskell.org. Please give reasons for your nomination. The current committee will appoint new commitee members and editors starting in the new year, so the deadline for nominations is 31 December 2009. During discussion amongst the current commitee, we realised that the choice of committee should be informed not just by the criteria above, but also by the particular proposals that are expected to be under consideration during this cycle. With that in mind, we plan that following the nominations the current committee will choose a core commitee of up to 10 members, and further members may be appointed during the year based on expertise needed to consider particular proposals. Accordingly, now would be a good time to start discussing which proposals should be considered in the Haskell 2011 timeframe, as that may affect the choice of commitee members. More details on the current Haskell Prime process are here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
