Re: [Haskell] Status of Haskell'?

[Jason Dusek]

2012/11/30 Gábor Lehel :
> Well, I'm not so sure it's a great idea to just bake "what GHC
> does at this moment" (for any particular extension) into the
> standard without really thinking about it. Even then, you have
> to figure out, in great detail, what GHC does, and write it
> all down! That's not negligible effort, either. And the
> alternative is to also publicly discuss and hash all of it out
> down to the little tiny gritty stuff. But wanting to write a
> new standard (big effort!) just to get rid of some pragmas and
> make people feel better (small payoff!) feels like a mismatch
> to me.

It is a large payoff, considering the thousands and thousands of
people that it creates a small payoff for: people writing
Haskell, people learning Haskell, people teaching Haskell. A
standard is a lot of effort for a handful of people.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Jason Dusek]

2012/12/1 Tijn van der Zant :
> I think that there is more to take into account.
> Haskell is growing as a language that people use to solve scientific and
> business problems. It is starting to become more of a working language,
> which is a very good thing of course. But this also means that Haskell
> should accommodate the people who are only working with it (not developing
> the language) and might not have a clue about the developers of the
> language. I'm somewhere in between where I love to read about the
> developments (this is my first post) and use it to program robots in my lab
> (besides some other languages).
> To accommodate the people who just want to use Haskell, we might have a
> super-pragma (as previously proposed) and for those gaining skill it should
> be possible to subtract pragmas until you have turned them all off and you
> can call yourself a Haskell guru. Mind you, I am not one of those, simply
> because I have to program in 5 languages for my work. For me, all those
> pragmas are not a matter of ugliness, but more an annoyance. For starters it
> is even worse. They ask questions such as: What do I turn on? Did I already
> find a good pragma tutorial? Why do I need to know about pragmas if it is
> already difficult to learn the language? By subtracting the pragmas (or
> turning them off) people can learn what they actually do and improve their
> code and their thinking about the language.
> Quite often I need the get something done, and due to time pressure I do not
> always have the luxury to make the code beautiful. And since it is Haskell
> (if it compiles it probably does what you want) I do not always care. For
> many users, pragmas are a Haskell concept that they can live without in the
> first part of their Haskell programming career (and they just turn a load of
> them on without even thinking about it what they do, but hey, the code works
> now!...)
> I think that we should accommodate the 'working programmers' and make their
> life a little bit easier, so that it becomes easier to start programming in
> Haskell and the language can be put to use by more people.
> This does not exclude having a 'pragma prime' that includes proposals for
> Haskell' of course. But it would help people starting with Haskell a lot
> imho.

Thank you for highlighting the many ways in which pragmas are
a problem from a practical point of view.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Roman Cheplyaka]

* Simon Peyton-Jones  [2012-11-30 16:36:01+]
> Why not?  I don't think it's laziness or selfishness; just look at how
> helpful people are on the mailing list.  Rather, I am guessing that
> it's a subconscious assessment of cost/benefit.  The cost is certainly
> significant, and (unlike a quick email response on Haskell Cafe) takes
> place over months.
> 
> The benefit, for an individual, is harder to articulate.   GHC defines
> a de-facto standard, simply by existing, and for many practical
> purposes that is good enough.  However, GHC is (quite consciously)
> exploring stuff that may or may not ultimately turn out to be a good
> idea: it's a laboratory, not an every-detail-thought-out product.
> [Though of course we try hard to be good enough for production use.]
> So there is real merit in having a group, not too closely coupled to
> GHC, that picks off the best ideas and embodies them in a language
> standard.   But if for any one individual, GHC is "good enough", then
> the benefits of a language standard may seem distant and diffuse.
> 
> I don't have a solution to this particular conundrum.  As many of you
> will remember, the Haskell Prime
> process
> was itself developed in response to a sense that making a "big
> iteration" of the language was so large a task that no one felt able
> to even begin it.  Hence the deliberately more incremental nature of
> Haskell Prime; but even this lighter-weight process is rather stuck.
> 
> I'm sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell's language definition.  I'm copying this to the
> main Haskell list, in the hope of attracting volunteers!

Thanks — I think this is a good analysis of the situation.

One thing I'd like to add is that working on the standard not only
takes more effort compared to responding on the mailing list, but it
also requires a much higher level of competence.

Roman

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Roman Cheplyaka]

* Tijn van der Zant  [2012-12-01 10:00:31+0100]
> Why do I need to know about pragmas if it is already difficult to
> learn the language?

Exactly. In an ideal world, where the language standard corresponds to
what people perceive as being standard, beginners shouldn't know or care
about pragmas, which by definition enable non-portable and experimental
features.

And the last thing a beginner should do is to enable ALL of those
obscure features.

> (and they just turn a load of them on without even thinking about it
> what they do, but hey, the code works now!...)

That is an unfortunate situation in which we are now, and which could be
improved by releasing a new standard incorporating the most tested and
widely-used features.

Roman

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Roman Cheplyaka]

* Henning Thielemann  [2012-12-01 00:37:12+0100]
> We should have multiple implementations before standardization.

Alternative implementations already exist for lots of extenstions, see
http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions

Roman

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Tijn van der Zant]

Hi All,

I think that there is more to take into account.
Haskell is growing as a language that people use to solve scientific and
business problems. It is starting to become more of a working language,
which is a very good thing of course. But this also means that Haskell
should accommodate the people who are only working with it (not developing
the language) and might not have a clue about the developers of the
language. I'm somewhere in between where I love to read about the
developments (this is my first post) and use it to program robots in my lab
(besides some other languages).
To accommodate the people who just want to use Haskell, we might have a
super-pragma (as previously proposed) and for those gaining skill it should
be possible to subtract pragmas until you have turned them all off and you
can call yourself a Haskell guru. Mind you, I am not one of those, simply
because I have to program in 5 languages for my work. For me, all those
pragmas are not a matter of ugliness, but more an annoyance. For starters
it is even worse. They ask questions such as: What do I turn on? Did I
already find a good pragma tutorial? Why do I need to know about pragmas if
it is already difficult to learn the language? By subtracting the pragmas
(or turning them off) people can learn what they actually do and improve
their code and their thinking about the language.
Quite often I need the get something done, and due to time pressure I do
not always have the luxury to make the code beautiful. And since it is
Haskell (if it compiles it probably does what you want) I do not always
care. For many users, pragmas are a Haskell concept that they can live
without in the first part of their Haskell programming career (and they
just turn a load of them on without even thinking about it what they do,
but hey, the code works now!...)
I think that we should accommodate the 'working programmers' and make their
life a little bit easier, so that it becomes easier to start programming in
Haskell and the language can be put to use by more people.
This does not exclude having a 'pragma prime' that includes proposals for
Haskell' of course. But it would help people starting with Haskell a lot
imho.

Cheers,

Tijn


On Sat, Dec 1, 2012 at 12:37 AM, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:

>
> On Sat, 1 Dec 2012, Gábor Lehel wrote:
>
>  On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares  wrote:
>>
>>>
>>> +1. I agree generally with Gabor's points -- GHC is in the drivers seat.
>>> But
>>> at some point we should take a look at all the things GHC has made that
>>> did
>>> pay off and that are good and make them official.
>>>
>>> I'd very much like to see that endorsement happen soon, even if it's not
>>> aggressive.
>>>
>>
>> Well, I'm not so sure it's a great idea to just bake "what GHC does at
>> this moment" (for any particular extension) into the standard without
>> really thinking about it. Even then, you have to figure out, in great
>> detail, what GHC does, and write it all down! That's not negligible
>> effort, either. And the alternative is to also publicly discuss and
>> hash all of it out down to the little tiny gritty stuff. But wanting
>> to write a new standard (big effort!) just to get rid of some pragmas
>> and make people feel better (small payoff!) feels like a mismatch to
>> me.
>>
>
> In my opinion it is a good thing if people feel bad about a lot of
> LANGUAGE pragmas at top of their modules. For me the number of LANGUAGE
> pragmas is a (reciprocal) measure of how much effort the programmer
> invested in cleaning up the code. In the past I removed a lot of
> FlexibleInstances, FlexibleContexts, UndecidableInstances,
> TypeSynonymInstances, PatternGuards and _improved_ the code this way. The
> need for generalized instances is often caused by badly designed classes or
> types. For me many extensions are a way to get a working implementation
> quickly from which I can derive a simpler one by throwing out extensions
> successively. I would also like to tell students that if they need to
> enable language extensions (or specific set of extensions) then they are
> solving a task in a too complicated way.
>
> I like to support Gábors arguments. We should have multiple
> implementations before standardization. E.g. I remember how TypeFamilies
> have evolved over the time or how the interaction of the forall quantifier
> with ($) changed between versions of GHC - how can we get confidence that
> GHC implemented these features in the most reasonable way?
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Henning Thielemann]

On Sat, 1 Dec 2012, Gábor Lehel wrote:


On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares  wrote:


+1. I agree generally with Gabor's points -- GHC is in the drivers seat. But
at some point we should take a look at all the things GHC has made that did
pay off and that are good and make them official.

I'd very much like to see that endorsement happen soon, even if it's not
aggressive.


Well, I'm not so sure it's a great idea to just bake "what GHC does at
this moment" (for any particular extension) into the standard without
really thinking about it. Even then, you have to figure out, in great
detail, what GHC does, and write it all down! That's not negligible
effort, either. And the alternative is to also publicly discuss and
hash all of it out down to the little tiny gritty stuff. But wanting
to write a new standard (big effort!) just to get rid of some pragmas
and make people feel better (small payoff!) feels like a mismatch to
me.


In my opinion it is a good thing if people feel bad about a lot of 
LANGUAGE pragmas at top of their modules. For me the number of LANGUAGE 
pragmas is a (reciprocal) measure of how much effort the programmer 
invested in cleaning up the code. In the past I removed a lot of 
FlexibleInstances, FlexibleContexts, UndecidableInstances, 
TypeSynonymInstances, PatternGuards and _improved_ the code this way. The 
need for generalized instances is often caused by badly designed classes 
or types. For me many extensions are a way to get a working implementation 
quickly from which I can derive a simpler one by throwing out extensions 
successively. I would also like to tell students that if they need to 
enable language extensions (or specific set of extensions) then they are 
solving a task in a too complicated way.


I like to support Gábors arguments. We should have multiple 
implementations before standardization. E.g. I remember how TypeFamilies 
have evolved over the time or how the interaction of the forall quantifier 
with ($) changed between versions of GHC - how can we get confidence that 
GHC implemented these features in the most reasonable way?
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Gábor Lehel]

On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares  wrote:
>
>> This standardization process amounts to "endorsement of existing
>> features" which seems like not a bad process at all. It makes
>> the standard descriptive rather than predictive.
>
>
> +1. I agree generally with Gabor's points -- GHC is in the drivers seat. But
> at some point we should take a look at all the things GHC has made that did
> pay off and that are good and make them official.
>
> I'd very much like to see that endorsement happen soon, even if it's not
> aggressive.

Well, I'm not so sure it's a great idea to just bake "what GHC does at
this moment" (for any particular extension) into the standard without
really thinking about it. Even then, you have to figure out, in great
detail, what GHC does, and write it all down! That's not negligible
effort, either. And the alternative is to also publicly discuss and
hash all of it out down to the little tiny gritty stuff. But wanting
to write a new standard (big effort!) just to get rid of some pragmas
and make people feel better (small payoff!) feels like a mismatch to
me.

Maybe as some kind of useful in-between point, the GHC folks could
figure out which extensions they like enough that they would, modulo
all the details getting figured out and specified, be in favor of them
going into a new standard, and fold all of them into a new LANGUAGE
definition? So then you would write {-# LANGUAGE HaskellNext #-}, or
HaskellGHC, or something like that, to enable all of them in one go.
That wouldn't require specifying things down to the tiniest details
(which is what a standard requires), but only at the granularity of
particular extensions, which is what people seem to be looking for.
Maybe instead of the GHC people deciding it, there could be some kind
of community process (such as a vote). (And yeah, this sounds eerily
similar to -fglasgow-exts, which is what we got rid of in favor of
LANGUAGE pragmas, but maybe the fact that -fglasgow-exts turned mostly
all extensions on indiscriminately, whereas this would be a curated
subset, is a significant enough difference to turn it from a bad idea
into a good one.)


-- 
Your ship was destroyed in a monadic eruption.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Johan Tibell]

On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek  wrote:
> It would be nice for there to be a new standard so that many
> features in GHC -- such as overloaded strings, rank n types,
> MPTCs, &c. -- were enabled by default without any pragmas.

I think this is one of these nice gains for day-to-day Haskell
programming. Less typing and fewer things to explain to beginners
("You see, this might seem like an experimental feature I'm asking you
to use, but it really isn't.")

-- Johan

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Jason Dusek]

2012/11/30 Gábor Lehel :
> Executive summary: We don't need a new standard right now. If
> people don't think it's worth their while to work on it,
> they're probably right. New, competing implementations might
> be valuable. If we have them, there will be demand for a
> standard, making decisions about it will be easier, and it
> will probably be better.

It would be nice for there to be a new standard so that many
features in GHC -- such as overloaded strings, rank n types,
MPTCs, &c. -- were enabled by default without any pragmas.

This standardization process amounts to "endorsement of existing
features" which seems like not a bad process at all. It makes
the standard descriptive rather than predictive.

--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Kim-Ee Yeoh]

On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel  wrote:

> > But in Haskell right now, for practical purposes, we don't
have competing implementations. We have GHC.

Isn't "putting pressure on the community" for a new standard a way to, umm,
implement wished-for features in GHC economically? ;)

-- Kim-Ee


On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel  wrote:

> On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones
>  wrote:
> > I'd argue that it's not. Haskell hasn't had a release in years, and I
> think
> > it's time to put a little pressure on the community.
> >
> >
> >
> > The question is: who is “the community”?
> >
> >
> >
> > It’s fairly clear that the Haskell Prime process itself is languishing.
> The
> > last message about the development process that I can find is this one
> from
> > Malcolm Wallace, in January 2011.
> >
> >
> >
> > But please don’t blame Malcolm or the committee.  Developing new,
> > well-specified changes to Haskell will only happen if there is a vigorous
> > eco-system of folk who are prepared to devote the love and time to do it.
> > There are plenty of people (myself among them) who would be delighted if
> > there was a series of well-specified updates to the Haskell standard;
> but it
> > is harder to assemble a group that is willing to move that process
> forward.
> >
> >
> >
> > Why not?  I don’t think it’s laziness or selfishness; just look at how
> > helpful people are on the mailing list.  Rather, I am guessing that it’s
> a
> > subconscious assessment of cost/benefit.  The cost is certainly
> significant,
> > and (unlike a quick email response on Haskell Cafe) takes place over
> months.
> >
> >
> >
> > The benefit, for an individual, is harder to articulate.   GHC defines a
> > de-facto standard, simply by existing, and for many practical purposes
> that
> > is good enough.  However, GHC is (quite consciously) exploring stuff that
> > may or may not ultimately turn out to be a good idea: it’s a laboratory,
> not
> > an every-detail-thought-out product.  [Though of course we try hard to be
> > good enough for production use.]  So there is real merit in having a
> group,
> > not too closely coupled to GHC, that picks off the best ideas and
> embodies
> > them in a language standard.   But if for any one individual, GHC is
> “good
> > enough”, then the benefits of a language standard may seem distant and
> > diffuse.
> >
> >
> >
> > I don’t have a solution to this particular conundrum.  As many of you
> will
> > remember, the Haskell Prime process was itself developed in response to a
> > sense that making a “big iteration” of the language was so large a task
> that
> > no one felt able to even begin it.  Hence the deliberately more
> incremental
> > nature of Haskell Prime; but even this lighter-weight process is rather
> > stuck.
> >
> >
> >
> > I’m sure that any solution will involve (as it did in earlier stages)
> > motivated individuals who are willing to take up leadership roles in
> > developing Haskell’s language definition.  I’m copying this to the main
> > Haskell list, in the hope of attracting volunteers!
> >
> >
> >
> > Simon
>
> To take a somewhat contrarian position, but with many of the same points:
>
> I don't think it's so terrible that the process is languishing. Of
> course, a new standard would be nice - so would a pony.* But a
> language standard is a solution to a problem that right now, we don't
> have.
>
> The situation when you really want a common standard is when you have
> multiple, competing, incompatible implementations. Programs that work
> with one implementation don't work with another, and there's no clear
> idea of what they "should" do, only what they do. It's really
> annoying, and impedes productivity. The solution is to create a
> standard that specifies the expected behaviour, and to make all of the
> implementations obey it. It's a lot of work, but the payoff is worth
> it. If your code works with one implementation, it's likely to work
> with another.
>
> But in Haskell right now, for practical purposes, we don't have
> competing implementations. We have GHC. If your code works with GHC,
> it's likely to work with GHC. (Heck, the main source of
> incompatibilities is /older and newer versions of GHC/.) People get
> their work done, their code works, there's no big problem. So while
> creating a standard is a lot of work, there's no clear payoff. People
> are making the calculation that they have more beneficial uses for
> their time than to work on Haskell' - and maybe they're right!
>
> If someone wants to "put pressure on the community" to work on a new
> standard, the thing to do would be to work on another implementation
> of Haskell(-with-extensions), and to get it to the point where a
> significant chunk of the community has reasons to prefer it over GHC.
> Even that feels a bit like putting the cart before the horse, though:
> the value would be more in the new, competing implementations and the
> different perspectives they aff

Re: [Haskell] Status of Haskell'?

[Gábor Lehel]

On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones
 wrote:
> I'd argue that it's not. Haskell hasn't had a release in years, and I think
> it's time to put a little pressure on the community.
>
>
>
> The question is: who is “the community”?
>
>
>
> It’s fairly clear that the Haskell Prime process itself is languishing. The
> last message about the development process that I can find is this one from
> Malcolm Wallace, in January 2011.
>
>
>
> But please don’t blame Malcolm or the committee.  Developing new,
> well-specified changes to Haskell will only happen if there is a vigorous
> eco-system of folk who are prepared to devote the love and time to do it.
> There are plenty of people (myself among them) who would be delighted if
> there was a series of well-specified updates to the Haskell standard; but it
> is harder to assemble a group that is willing to move that process forward.
>
>
>
> Why not?  I don’t think it’s laziness or selfishness; just look at how
> helpful people are on the mailing list.  Rather, I am guessing that it’s a
> subconscious assessment of cost/benefit.  The cost is certainly significant,
> and (unlike a quick email response on Haskell Cafe) takes place over months.
>
>
>
> The benefit, for an individual, is harder to articulate.   GHC defines a
> de-facto standard, simply by existing, and for many practical purposes that
> is good enough.  However, GHC is (quite consciously) exploring stuff that
> may or may not ultimately turn out to be a good idea: it’s a laboratory, not
> an every-detail-thought-out product.  [Though of course we try hard to be
> good enough for production use.]  So there is real merit in having a group,
> not too closely coupled to GHC, that picks off the best ideas and embodies
> them in a language standard.   But if for any one individual, GHC is “good
> enough”, then the benefits of a language standard may seem distant and
> diffuse.
>
>
>
> I don’t have a solution to this particular conundrum.  As many of you will
> remember, the Haskell Prime process was itself developed in response to a
> sense that making a “big iteration” of the language was so large a task that
> no one felt able to even begin it.  Hence the deliberately more incremental
> nature of Haskell Prime; but even this lighter-weight process is rather
> stuck.
>
>
>
> I’m sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell’s language definition.  I’m copying this to the main
> Haskell list, in the hope of attracting volunteers!
>
>
>
> Simon

To take a somewhat contrarian position, but with many of the same points:

I don't think it's so terrible that the process is languishing. Of
course, a new standard would be nice - so would a pony.* But a
language standard is a solution to a problem that right now, we don't
have.

The situation when you really want a common standard is when you have
multiple, competing, incompatible implementations. Programs that work
with one implementation don't work with another, and there's no clear
idea of what they "should" do, only what they do. It's really
annoying, and impedes productivity. The solution is to create a
standard that specifies the expected behaviour, and to make all of the
implementations obey it. It's a lot of work, but the payoff is worth
it. If your code works with one implementation, it's likely to work
with another.

But in Haskell right now, for practical purposes, we don't have
competing implementations. We have GHC. If your code works with GHC,
it's likely to work with GHC. (Heck, the main source of
incompatibilities is /older and newer versions of GHC/.) People get
their work done, their code works, there's no big problem. So while
creating a standard is a lot of work, there's no clear payoff. People
are making the calculation that they have more beneficial uses for
their time than to work on Haskell' - and maybe they're right!

If someone wants to "put pressure on the community" to work on a new
standard, the thing to do would be to work on another implementation
of Haskell(-with-extensions), and to get it to the point where a
significant chunk of the community has reasons to prefer it over GHC.
Even that feels a bit like putting the cart before the horse, though:
the value would be more in the new, competing implementations and the
different perspectives they afford, than in the new work on Haskell'
that they might inspire. But besides increasing demand for one, I do
think that this would have a positive effect on any hypothetical new
standard and on the process of arriving at it. When making decisions
about the expected behaviour, we would have a rich body of experience
to draw on from the different implementations. Right now, it looks
like "we know what GHC does" and then bikeshedding about "but maybe
another way would be better?", without experience to inform it.
Decisions are harder to make that way, and we can be less certain

Re: [Haskell] Status of Haskell'?

[Simon Peyton-Jones]

I'd argue that it's not. Haskell hasn't had a release in years, and I think 
it's time to put a little pressure on the community.

The question is: who is "the community"?

It's fairly clear that the Haskell Prime process itself is languishing. The 
last message about the development process that I can find is this one from 
Malcolm 
Wallace,
 in January 2011.

But please don't blame Malcolm or the 
committee.  
Developing new, well-specified changes to Haskell will only happen if there is 
a vigorous eco-system of folk who are prepared to devote the love and time to 
do it.  There are plenty of people (myself among them) who would be delighted 
if there was a series of well-specified updates to the Haskell standard; but it 
is harder to assemble a group that is willing to move that process forward.

Why not?  I don't think it's laziness or selfishness; just look at how helpful 
people are on the mailing list.  Rather, I am guessing that it's a subconscious 
assessment of cost/benefit.  The cost is certainly significant, and (unlike a 
quick email response on Haskell Cafe) takes place over months.

The benefit, for an individual, is harder to articulate.   GHC defines a 
de-facto standard, simply by existing, and for many practical purposes that is 
good enough.  However, GHC is (quite consciously) exploring stuff that may or 
may not ultimately turn out to be a good idea: it's a laboratory, not an 
every-detail-thought-out product.  [Though of course we try hard to be good 
enough for production use.]  So there is real merit in having a group, not too 
closely coupled to GHC, that picks off the best ideas and embodies them in a 
language standard.   But if for any one individual, GHC is "good enough", then 
the benefits of a language standard may seem distant and diffuse.

I don't have a solution to this particular conundrum.  As many of you will 
remember, the Haskell Prime 
process was itself 
developed in response to a sense that making a "big iteration" of the language 
was so large a task that no one felt able to even begin it.  Hence the 
deliberately more incremental nature of Haskell Prime; but even this 
lighter-weight process is rather stuck.

I'm sure that any solution will involve (as it did in earlier stages) motivated 
individuals who are willing to take up leadership roles in developing Haskell's 
language definition.  I'm copying this to the main Haskell list, in the hope of 
attracting volunteers!

Simon

From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares
Sent: 27 November 2012 22:44
To: Ben Millwood
Cc: haskell-pr...@haskell.org Prime
Subject: Re: Status of Haskell'?

> it might be wise to see what GHC decides to do on that front, first,

I'd argue that it's not. Haskell hasn't had a release in years, and I think 
it's time to put a little pressure on the community.

On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood 
mailto:hask...@benmachine.co.uk>> wrote:
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 
mailto:ig...@earth.li>> wrote:
> [...] adding DeriveDataTypeable
> hopefully wouldn't be too controversial [...]

This is a little tricky since the Data class itself makes (essential,
I think) use of Rank2Types. Typeable ought to be fine, but it might be
wise to see what GHC decides to do on that front, first, e.g. whether
it's going to autoderive all instances or forbid user instances or
anything else similarly bold.

___
Haskell-prime mailing list
haskell-pr...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell