Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

classic Classic list List threaded Threaded
243 messages Options
1 ... 78910111213
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Simon Peyton Jones
Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:

|  Proposal 2: After a suitable period of discussion on the libraries list, the
|  Core Libraries Committee will summarize the arguments for and against a
|  proposal and post it, along with a (justified) preliminary decision, to a
|  low-traffic, announce-only email list. After another suitable period of
|  discussion, they will issue a final decision. What is a suitable period of
|  time? Perhaps that depends on the properties of the proposal, such as
|  whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.

|  Personally, I think AMP was the right thing to do, but I don't think FTP was
|  the right thing.

These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.

Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek

 * transparency;
 * clarity about what decisions are on the table;
 * broad consultation about decisions that affect
    a broad constituency; and
 * a decent opportunity to debate them without having
    to be involved in massive email threads.  Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

|  Proposal 3: A decision regarding any proposal that significantly affects
|  backwards compatibility is within the purview of the Haskell Prime
|  Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Herbert Valerio Riedel-3
In reply to this post by Geoffrey Mainland
Hello,

On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:

[...]

> In effect, only those who actively follow the libraries list have had a
> voice in these decisions. Maybe that is what the community wants. I hope
> not. How then can people like me (and Henrik and Graham) have a say
> without committing to actively following the libraries list?
>  
> We have a method to solve this: elected representatives. Right now the
> Core Libraries Committee elects its own members; perhaps it is time for
> that to change.

[...]

> Proposal 1: Move to community election of the members of the Core
> Libraries Committee. Yes, I know this would have its own issues.

How exactly do public elections of representatives address the problem
that some people feel left out? Have you considered nominating yourself
or somebody else you have confidence in for the core libraries
committee? You'd still have to find somebody to represent your
interests, regardless of whether the committee is self-elected or
direct-elected.

Here's some food for thought regarding language design by voting or its
indirect form via a directly elected language committee:

Back in February there was a large-scale survey which resulted (see [2]
for more details) in a rather unequivocal 4:1 majority *for* going
through with the otherwise controversial FTP implementation. If the
community elections would result in a similar spirit, you'd could easily
end up with a similarly 4:1 pro-change biased committee. Would you
consider that a well balanced committee formation?

> Proposal 2: After a suitable period of discussion on the libraries list,
> the Core Libraries Committee will summarize the arguments for and
> against a proposal and post it, along with a (justified) preliminary
> decision, to a low-traffic, announce-only email list. After another
> suitable period of discussion, they will issue a final decision. What is
> a suitable period of time? Perhaps that depends on the properties of the
> proposal, such as whether it breaks backwards compatibility.

That generally sounds like a good compromise, if this actually helps
reaching the otherwise unreachable parts of the community and have their
voices heard.

> Proposal 3: A decision regarding any proposal that significantly affects
> backwards compatibility is within the purview of the Haskell Prime
> Committee, not the Core Libraries Committee.

I don't see how that would change much. The prior Haskell Prime
Committee has been traditionally self-elected as well. So it's just the
label of the committee you'd swap out.

In the recent call of nominations[1] for Haskell Prime, the stated area
of work for the new nominations was to take care of the *language* part,
because that's what we are lacking the workforce for.

Since its creation for the very purpose of watching over the core
libraries, the core-libraries-committee has been almost exclusively busy
with evaluating and deciding about changes to the `base` library and
overseeing their implementation. Transferring this huge workload to the
new Haskell Prime committee members who have already their hands full
with revising the language part would IMO just achieve to reduce the
effectiveness of the upcoming Haskell Prime committee, and therefore
increase the risk of failure in producing an adequate new Haskell Report
revision.

Regards,
  H.V.Riedel

 [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
 [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Jonathon Delgado
In reply to this post by Henrik Nilsson-2
Henrik Nilsson-2 wrote
Jeremy wrote:

 > There seems to be a fair amount of friction between those who want to
 > introduce new features or fix significant historical warts in the base
 > libraries - even if this requires breaking changes - and those who
 > insist on no significant breaking changes in new releases, regardless
 > of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that
is then outlined (Long-Term Support Haskell), I don't think this is
an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it
very clear that they are not at all against any breaking change. But
they oppose breaking changes to Haskell itself, including central
libraries, as defined by the Haskell report, unless the benefits are
very compelling indeed.
With equal respect, I stopped following the MRP thread when its length exceeded my interest, so my comments may not be applicable here :-)

The LTS solution should work as long as all (or at least a big enough majority) agree that the benefits of a  change are desirable, but disagree as to the cost of breaking change. It allows the "nice idea but don't keep breaking my code" people to co-exist with the "nice idea let's do it" people.
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Mike Meyer
In reply to this post by Herbert Valerio Riedel-3
On Wed, Oct 21, 2015 at 6:56 AM Herbert Valerio Riedel <[hidden email]> wrote:
> Proposal 1: Move to community election of the members of the Core
> Libraries Committee. Yes, I know this would have its own issues.
How exactly do public elections of representatives address the problem
that some people feel left out?

The issue of people feeling left out is addressed by the second part of his proposal, a low-volume (presumably announcements only) list where changes that are being seriously considered can be announced, along with pointers to the discussion areas. That way, the overhead of getting notices is near zero, and everyone can then decide whether to invest time in the 
 
Back in February there was a large-scale survey which resulted (see [2]
for more details) in a rather unequivocal 4:1 majority *for* going
through with the otherwise controversial FTP implementation. If the
community elections would result in a similar spirit, you'd could easily
end up with a similarly 4:1 pro-change biased committee. Would you
consider that a well balanced committee formation?

This shows two areas of confusion.

The first is that the point of representation isn't to be well-balanced, or fair, or any such thing. it's to be representative of the community. Or at least, of some aspect of the community.  Whether or not this is a problem and how to fix it are hard political problems that I doubt we're going to solve.

The second is that the composition of the committee matters beyond the aspect they are supposed to represent. For instance, if the process doesn't leave final decisions in the hands of the committee, but in a general vote (just a for instance, not a proposal) then the balance or fairness of the committee is irrelevant, so long as the community trusts them to administer the process properly.

In other words, we need to figure out exactly what the job of the committee is going to be before we start worrying about what kind of composition it should have.

As for the issue of libraries vs. language, I think the same process should apply to both, though it might be administered by different groups in order to spread the workload around. 
 

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
In reply to this post by Herbert Valerio Riedel-3
On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]
> >> In effect, only those who actively follow the libraries list have
had a >> voice in these decisions. Maybe that is what the community
wants. I hope >> not. How then can people like me (and Henrik and
Graham) have a say >> without committing to actively following the
libraries list? >>  >> We have a method to solve this: elected
representatives. Right now the >> Core Libraries Committee elects its
own members; perhaps it is time for >> that to change. > > [...] > >>
Proposal 1: Move to community election of the members of the Core >>
Libraries Committee. Yes, I know this would have its own issues. > > How
exactly do public elections of representatives address the problem >
that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries >
committee? You'd still have to find somebody to represent your >
interests, regardless of whether the committee is self-elected or >
direct-elected. > > Here's some food for thought regarding language
design by voting or its > indirect form via a directly elected language
committee: > > Back in February there was a large-scale survey which
resulted (see [2] > for more details) in a rather unequivocal 4:1
majority *for* going > through with the otherwise controversial FTP
implementation. If the > community elections would result in a similar
spirit, you'd could easily > end up with a similarly 4:1 pro-change
biased committee. Would you > consider that a well balanced committee
formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >>
against a proposal and post it, along with a (justified) preliminary >>
decision, to a low-traffic, announce-only email list. After another >>
suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of
the >> proposal, such as whether it breaks backwards compatibility. > >
That generally sounds like a good compromise, if this actually helps >
reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee. > > I don't see how that
would change much. The prior Haskell Prime > Committee has been
traditionally self-elected as well. So it's just the > label of the
committee you'd swap out. > > In the recent call of nominations[1] for
Haskell Prime, the stated area > of work for the new nominations was to
take care of the *language* part, > because that's what we are lacking
the workforce for. > > Since its creation for the very purpose of
watching over the core > libraries, the core-libraries-committee has
been almost exclusively busy > with evaluating and deciding about
changes to the `base` library and > overseeing their implementation.
Transferring this huge workload to the > new Haskell Prime committee
members who have already their hands full > with revising the language
part would IMO just achieve to reduce the > effectiveness of the
upcoming Haskell Prime committee, and therefore > increase the risk of
failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that
correct?

Cheers,
Geoff

> Regards, >   H.V.Riedel > >  [1]:
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]:
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Kim-Ee Yeoh
Administrator
In reply to this post by Jonathon Delgado

On Wed, Oct 21, 2015 at 7:18 PM, Jeremy <[hidden email]> wrote:
The LTS solution should work as long as all (or at least a big enough
majority) agree that the benefits of a  change are desirable, but disagree
as to the cost of breaking change. It allows the "nice idea but don't keep
breaking my code" people to co-exist with the "nice idea let's do it"
people.

But as Henrik and Lennart have alluded to, what we have currently is friction between "half-baked idea, I'll fight against it" and "nice idea, this is the way to progress."

LTS, seen in this light, is a discussion-postponing move.

What's needed is a "let's agree to disagree and have a long, deep discussion to understand one another", not "let's agree to disagree. Here's software for you. And here's software for me. Bye-bye."

-- Kim-Ee

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Jonathon Delgado
Kim-Ee Yeoh wrote
But as Henrik and Lennart have alluded to, what we have currently is
friction between "half-baked idea, I'll fight against it" and "nice idea,
this is the way to progress."

LTS, seen in this light, is a discussion-postponing move.

What's needed is a "let's agree to disagree and have a long, deep
discussion to understand one another", not "let's agree to disagree. Here's
software for you. And here's software for me. Bye-bye."
Indeed, LTS is only relevant after a proposal has been agreed upon in principle, and the only issue is whether it's worth a breaking change. AMP may be a good example of where this would help.
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Matthias Hörmann
It might also be relevant to note that any LTS release will lead to even
more surprises about things that happened in the more regular releases
and a correspondingly reduced influence on the direction of Haskell for those
who only use the LTS releases and do not pay attention to the language
or library changes in the regular releases in between two LTS releases.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Jonathon Delgado
My rationale for proposing LTS as a solution is that this is the model which enterprise users have already adopted this for other technologies, despite the big jump between releases. I'm not theorising about a proposition which may work for users seeking long-term stability, I'm describing the solution which they're already using and happy with for other technologies.
Reply | Threaded
Open this post in threaded view
|

Re: Committee M.O. Change Proposals

Geoffrey Mainland
In reply to this post by Herbert Valerio Riedel-3
Apologies for the previous mailer-mangled "draft"...

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:

> Hello,
>
> On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote:
>
> [...]
>
>> In effect, only those who actively follow the libraries list have had a
>> voice in these decisions. Maybe that is what the community wants. I hope
>> not. How then can people like me (and Henrik and Graham) have a say
>> without committing to actively following the libraries list?
>>  
>> We have a method to solve this: elected representatives. Right now the
>> Core Libraries Committee elects its own members; perhaps it is time for
>> that to change.
> [...]
>
>> Proposal 1: Move to community election of the members of the Core
>> Libraries Committee. Yes, I know this would have its own issues.
> How exactly do public elections of representatives address the problem
> that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries
> committee? You'd still have to find somebody to represent your
> interests, regardless of whether the committee is self-elected or
> direct-elected.
>
> Here's some food for thought regarding language design by voting or its
> indirect form via a directly elected language committee:
>
> Back in February there was a large-scale survey which resulted (see [2]
> for more details) in a rather unequivocal 4:1 majority *for* going
> through with the otherwise controversial FTP implementation. If the
> community elections would result in a similar spirit, you'd could easily
> end up with a similarly 4:1 pro-change biased committee. Would you
> consider that a well balanced committee formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list,
>> the Core Libraries Committee will summarize the arguments for and
>> against a proposal and post it, along with a (justified) preliminary
>> decision, to a low-traffic, announce-only email list. After another
>> suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of the
>> proposal, such as whether it breaks backwards compatibility.
> That generally sounds like a good compromise, if this actually helps
> reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects
>> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee.
> I don't see how that would change much. The prior Haskell Prime
> Committee has been traditionally self-elected as well. So it's just the
> label of the committee you'd swap out.
>
> In the recent call of nominations[1] for Haskell Prime, the stated area
> of work for the new nominations was to take care of the *language* part,
> because that's what we are lacking the workforce for.
>
> Since its creation for the very purpose of watching over the core
> libraries, the core-libraries-committee has been almost exclusively busy
> with evaluating and deciding about changes to the `base` library and
> overseeing their implementation. Transferring this huge workload to the
> new Haskell Prime committee members who have already their hands full
> with revising the language part would IMO just achieve to reduce the
> effectiveness of the upcoming Haskell Prime committee, and therefore
> increase the risk of failure in producing an adequate new Haskell Report
> revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that correct?

Cheers,
Geoff

> Regards,
>   H.V.Riedel
>
>  [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Geoffrey Mainland
In reply to this post by Simon Peyton Jones
On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

> Friends
>
> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>
> |  Proposal 2: After a suitable period of discussion on the libraries list, the
> |  Core Libraries Committee will summarize the arguments for and against a
> |  proposal and post it, along with a (justified) preliminary decision, to a
> |  low-traffic, announce-only email list. After another suitable period of
> |  discussion, they will issue a final decision. What is a suitable period of
> |  time? Perhaps that depends on the properties of the proposal, such as
> |  whether it breaks backwards compatibility.
>
> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>
> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
> |  the right thing.
>
> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>
> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>
>  * transparency;
>  * clarity about what decisions are on the table;
>  * broad consultation about decisions that affect
>     a broad constituency; and
>  * a decent opportunity to debate them without having
>     to be involved in massive email threads.  Let's try do to that.
>
> Simon
>
> PS: For what it's worth I'm less keen on Geoff's other proposal:
>
> |  Proposal 3: A decision regarding any proposal that significantly affects
> |  backwards compatibility is within the purview of the Haskell Prime
> |  Committee, not the Core Libraries Committee.
>
> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective
responsibilities of the core libraries committee and Haskell Prime
committees are.

One possible choice is that the core libraries committee is responsible
for changes to the core libraries that do not affect libraries in the
report. It is meant to be nimble, able to quickly deal with the large
volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer
deliberative process, would consider the more impactful library changes
and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime
committee risks pushing the issue around. The idea behind the separation
outlined above is to reduce the treadmill; the two bodies use different
processes, with different time frames, to arrive at decisions. Some
library decisions may deserve a longer deliberative process.

Cheers,
Geoff
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

evan@evan-borden.com

I'd also like to raise my concerns about an LTS solution.

#1 incremental change is far more consumable than large blocks of change. We all know the fable of python 3, perl 6, etc.

#2 One concern that has been voiced by departing maintainers is the burden of maintaining compatibility. An LTS strategy only increases this burden by extending dead code paths.

On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" <[hidden email]> wrote:
On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
> Friends
>
> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>
> |  Proposal 2: After a suitable period of discussion on the libraries list, the
> |  Core Libraries Committee will summarize the arguments for and against a
> |  proposal and post it, along with a (justified) preliminary decision, to a
> |  low-traffic, announce-only email list. After another suitable period of
> |  discussion, they will issue a final decision. What is a suitable period of
> |  time? Perhaps that depends on the properties of the proposal, such as
> |  whether it breaks backwards compatibility.
>
> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>
> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
> |  the right thing.
>
> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>
> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>
>  * transparency;
>  * clarity about what decisions are on the table;
>  * broad consultation about decisions that affect
>     a broad constituency; and
>  * a decent opportunity to debate them without having
>     to be involved in massive email threads.  Let's try do to that.
>
> Simon
>
> PS: For what it's worth I'm less keen on Geoff's other proposal:
>
> |  Proposal 3: A decision regarding any proposal that significantly affects
> |  backwards compatibility is within the purview of the Haskell Prime
> |  Committee, not the Core Libraries Committee.
>
> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective
responsibilities of the core libraries committee and Haskell Prime
committees are.

One possible choice is that the core libraries committee is responsible
for changes to the core libraries that do not affect libraries in the
report. It is meant to be nimble, able to quickly deal with the large
volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer
deliberative process, would consider the more impactful library changes
and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime
committee risks pushing the issue around. The idea behind the separation
outlined above is to reduce the treadmill; the two bodies use different
processes, with different time frames, to arrive at decisions. Some
library decisions may deserve a longer deliberative process.

Cheers,
Geoff
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Kim-Ee Yeoh
Administrator
In reply to this post by Simon Peyton Jones
Hi Simon,

I'd just like you to know that the Haskell 98 report, for which you served as co-editor, played a very important role when I was teaching myself the language.

In fact, I still refer to it from time to time, both in the language and also the libraries section.

Which brings me to your email earlier this month:

https://mail.haskell.org/pipermail/haskell-prime/2015-October/003984.html

I think that keeping the CLC and HPC separate has a lot of advantages. Most important of all is keeping the work tractable by fanning it out. And the track record speaks for itself: progress is made.

While it made plenty of sense the last time round when it felt like squeezing blood from a stone assembling a quorum for HPC, wouldn't you say it's different this time around?

There's a buzz of enthusiasm in HPC self-nominations that signals a very healthy community, yes?

Some of that enthusiasm spills over into issues concerning the standard libraries.

Now given that FTP is a done deal, wouldn't you say that it deserves to be canonized in a report too? Just like Haskell 98?

I'm not saying to do away with the walls that separate the CLC and HPC. I'm saying that today presents a rare opportunity for a unified committee to work at a report good for the next 20 years.

Wouldn't it be such a waste to lose the moment?



*Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues.



-- Kim-Ee

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Christopher Allen
In reply to this post by evan@evan-borden.com
Seconding Evan Borden's concerns. I don't think LTS is needed for GHC itself, though FPComplete's LTS Stackage snapshots have been nice, that's on a timescale of months and there are multiple snapshots a year.

An LTS proposal at this time seems like delay for the sake of delay. The practitioners and learners I know have not found switching to 7.10 to be troublesome or to require much time. Converting http://haskellbook.com/ to be up to date with 7.10 took an hour or two. We waited to see (out of curiosity) if anybody would ask about the new type signatures. A few did, so we made note of the more general type signatures in the new Prelude, and showed them how you could assert a more specific (concrete) type signature for those functions. No problems since then. When they type in the example or exercise code, a type signature is provided which asserts that we want the list variant. Polymorphism in Haskell pays off in spades here.

I use Haskell at work, converting the 15-ish libraries (some vendored variants of public libraries) and 3 core projects totaling ~100k LOC took an hour. As long as programmers can get a checklist of things to fix from the compiler, I don't think this is a serious problem for industrial users. Companies will fix their GHC version and pick a date to switch over generally, needing to change things before cutting over shouldn't come as a surprise to anyone.


On Wed, Oct 21, 2015 at 10:48 AM, [hidden email] <[hidden email]> wrote:

I'd also like to raise my concerns about an LTS solution.

#1 incremental change is far more consumable than large blocks of change. We all know the fable of python 3, perl 6, etc.

#2 One concern that has been voiced by departing maintainers is the burden of maintaining compatibility. An LTS strategy only increases this burden by extending dead code paths.

On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" <[hidden email]> wrote:
On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
> Friends
>
> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>
> |  Proposal 2: After a suitable period of discussion on the libraries list, the
> |  Core Libraries Committee will summarize the arguments for and against a
> |  proposal and post it, along with a (justified) preliminary decision, to a
> |  low-traffic, announce-only email list. After another suitable period of
> |  discussion, they will issue a final decision. What is a suitable period of
> |  time? Perhaps that depends on the properties of the proposal, such as
> |  whether it breaks backwards compatibility.
>
> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>
> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
> |  the right thing.
>
> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>
> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>
>  * transparency;
>  * clarity about what decisions are on the table;
>  * broad consultation about decisions that affect
>     a broad constituency; and
>  * a decent opportunity to debate them without having
>     to be involved in massive email threads.  Let's try do to that.
>
> Simon
>
> PS: For what it's worth I'm less keen on Geoff's other proposal:
>
> |  Proposal 3: A decision regarding any proposal that significantly affects
> |  backwards compatibility is within the purview of the Haskell Prime
> |  Committee, not the Core Libraries Committee.
>
> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective
responsibilities of the core libraries committee and Haskell Prime
committees are.

One possible choice is that the core libraries committee is responsible
for changes to the core libraries that do not affect libraries in the
report. It is meant to be nimble, able to quickly deal with the large
volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer
deliberative process, would consider the more impactful library changes
and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime
committee risks pushing the issue around. The idea behind the separation
outlined above is to reduce the treadmill; the two bodies use different
processes, with different time frames, to arrive at decisions. Some
library decisions may deserve a longer deliberative process.

Cheers,
Geoff
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries




--
Chris Allen
Currently working on http://haskellbook.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Committee M.O. Change Proposals

Edward Kmett-2
In reply to this post by Geoffrey Mainland
The committee was formed from a pool of suggestions supplied to SPJ that represented a fairly wide cross-section of the community.

Simon initially offered both myself and Johan Tibell the role of co-chairs. Johan ultimately declined.

In the end, putting perhaps too simple a spin on it, the initial committee was selected: Michael Snoyman for commercial interest, Mark Lentczner representing the needs of the Platform and implementation concerns, Brent Yorgey on the theory side, Doug Beardsley representing practitioners, Joachim Breitner had expressed interest in working on split base, which at the time was a much more active concern, Dan Doel represented a decent balance of theory and practice.

Since then we had two slots open up on the committee, and precisely two self-nominations to fill them, which rather simplified the selection process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman rotated in.

Technically, yes, we are self-selected going forward, based on the precedent of the haskell.org committee and haskell-prime committees, but you'll note this hasn't actually been a factor yet as there hasn't been any decision point reached where that has affected a membership decision.

-Edward

On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland <[hidden email]> wrote:
On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
> Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]
> >> In effect, only those who actively follow the libraries list have
had a >> voice in these decisions. Maybe that is what the community
wants. I hope >> not. How then can people like me (and Henrik and
Graham) have a say >> without committing to actively following the
libraries list? >>  >> We have a method to solve this: elected
representatives. Right now the >> Core Libraries Committee elects its
own members; perhaps it is time for >> that to change. > > [...] > >>
Proposal 1: Move to community election of the members of the Core >>
Libraries Committee. Yes, I know this would have its own issues. > > How
exactly do public elections of representatives address the problem >
that some people feel left out? Have you considered nominating yourself
> or somebody else you have confidence in for the core libraries >
committee? You'd still have to find somebody to represent your >
interests, regardless of whether the committee is self-elected or >
direct-elected. > > Here's some food for thought regarding language
design by voting or its > indirect form via a directly elected language
committee: > > Back in February there was a large-scale survey which
resulted (see [2] > for more details) in a rather unequivocal 4:1
majority *for* going > through with the otherwise controversial FTP
implementation. If the > community elections would result in a similar
spirit, you'd could easily > end up with a similarly 4:1 pro-change
biased committee. Would you > consider that a well balanced committee
formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same
committee. I wouldn't see that as a negative outcome at all! At least
that committee would have been put in place by direct election; I would
see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had
it been in place at the time, would have increased participation in the
survey.

The recent kerfuffle has caught the attention of many people who don't
normally follow the libraries list. Proposal 1 is an attempt to give
them a voice. Yes, they would still need to find a candidate to
represent their interests. If we moved to direct elections, I would
consider running. However, my preference is that Proposal 3 go through
in some form, in which case my main concern would be the Haskell Prime
committee, and unfortunately nominations for that committee have already
closed.

>> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >>
against a proposal and post it, along with a (justified) preliminary >>
decision, to a low-traffic, announce-only email list. After another >>
suitable period of discussion, they will issue a final decision. What is
>> a suitable period of time? Perhaps that depends on the properties of
the >> proposal, such as whether it breaks backwards compatibility. > >
That generally sounds like a good compromise, if this actually helps >
reaching the otherwise unreachable parts of the community and have their
> voices heard.

My hope is that a low-volume mailing list would indeed reach a wider
audience.

>> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime
>> Committee, not the Core Libraries Committee. > > I don't see how that
would change much. The prior Haskell Prime > Committee has been
traditionally self-elected as well. So it's just the > label of the
committee you'd swap out. > > In the recent call of nominations[1] for
Haskell Prime, the stated area > of work for the new nominations was to
take care of the *language* part, > because that's what we are lacking
the workforce for. > > Since its creation for the very purpose of
watching over the core > libraries, the core-libraries-committee has
been almost exclusively busy > with evaluating and deciding about
changes to the `base` library and > overseeing their implementation.
Transferring this huge workload to the > new Haskell Prime committee
members who have already their hands full > with revising the language
part would IMO just achieve to reduce the > effectiveness of the
upcoming Haskell Prime committee, and therefore > increase the risk of
failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries
committee does not "significantly affect backwards compatibility," at
least not to the extent that MRP does. If this is the case, the bulk of
their workload would not be transferred to the new Haskell Prime
committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the
issues that come before the core libraries committee to the Haskell
Prime committee. In any case, we would certainly need to clarify what
"significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime
committee as well as changing their mandate to include some subset of
the changes proposed to libraries covered by the Haskell Report. My
understanding of the current state of affairs is that the Haskell Prime
committee is charged with producing a new report, but the core libraries
committee is in charge of the library part of that report. Is that
correct?

Cheers,
Geoff

> Regards, >   H.V.Riedel > >  [1]:
https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>  [2]:
https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] Committee M.O. Change Proposals

Geoffrey Mainland
Thanks for the background, Edward.

I don't mean to question the composition of the committee, only to start
a discussion about how the community might handle the selection process
going forward. I apologize if I was not clear about that. As I said
below, if a direct vote resulted in the same committee we would have had
under the current system, I would consider that a success!

We may also see a larger nomination pool in the future :)

Cheers,
Geoff

On 10/21/2015 03:54 PM, Edward Kmett wrote:

> The committee was formed from a pool of suggestions supplied to SPJ
> that represented a fairly wide cross-section of the community.
>
> Simon initially offered both myself and Johan Tibell the role of
> co-chairs. Johan ultimately declined.
>
> In the end, putting perhaps too simple a spin on it, the initial
> committee was selected: Michael Snoyman for commercial interest, Mark
> Lentczner representing the needs of the Platform and implementation
> concerns, Brent Yorgey on the theory side, Doug Beardsley representing
> practitioners, Joachim Breitner had expressed interest in working on
> split base, which at the time was a much more active concern, Dan Doel
> represented a decent balance of theory and practice.
>
> Since then we had two slots open up on the committee, and precisely
> two self-nominations to fill them, which rather simplified the
> selection process. Brent and Doug rotated out and Eric Mertens and
> Luite Stegeman rotated in.
>
> Technically, yes, we are self-selected going forward, based on the
> precedent of the haskell.org <http://haskell.org> committee and
> haskell-prime committees, but you'll note this hasn't actually been a
> factor yet as there hasn't been any decision point reached where that
> has affected a membership decision.
>
> -Edward
>
> On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote:
>     > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland
>     wrote: > > [...]
>     > >> In effect, only those who actively follow the libraries list have
>     had a >> voice in these decisions. Maybe that is what the community
>     wants. I hope >> not. How then can people like me (and Henrik and
>     Graham) have a say >> without committing to actively following the
>     libraries list? >>  >> We have a method to solve this: elected
>     representatives. Right now the >> Core Libraries Committee elects its
>     own members; perhaps it is time for >> that to change. > > [...] > >>
>     Proposal 1: Move to community election of the members of the Core >>
>     Libraries Committee. Yes, I know this would have its own issues. >
>     > How
>     exactly do public elections of representatives address the problem >
>     that some people feel left out? Have you considered nominating
>     yourself
>     > or somebody else you have confidence in for the core libraries >
>     committee? You'd still have to find somebody to represent your >
>     interests, regardless of whether the committee is self-elected or >
>     direct-elected. > > Here's some food for thought regarding language
>     design by voting or its > indirect form via a directly elected
>     language
>     committee: > > Back in February there was a large-scale survey which
>     resulted (see [2] > for more details) in a rather unequivocal 4:1
>     majority *for* going > through with the otherwise controversial FTP
>     implementation. If the > community elections would result in a similar
>     spirit, you'd could easily > end up with a similarly 4:1 pro-change
>     biased committee. Would you > consider that a well balanced committee
>     formation?
>
>     Thanks, all good points.
>
>     It is quite possible that direct elections would produce the exact
>     same
>     committee. I wouldn't see that as a negative outcome at all! At least
>     that committee would have been put in place by direct election; I
>     would
>     see that as strengthening their mandate.
>
>     I am very much aware of the February survey. I wonder if Proposal
>     2, had
>     it been in place at the time, would have increased participation
>     in the
>     survey.
>
>     The recent kerfuffle has caught the attention of many people who don't
>     normally follow the libraries list. Proposal 1 is an attempt to give
>     them a voice. Yes, they would still need to find a candidate to
>     represent their interests. If we moved to direct elections, I would
>     consider running. However, my preference is that Proposal 3 go through
>     in some form, in which case my main concern would be the Haskell Prime
>     committee, and unfortunately nominations for that committee have
>     already
>     closed.
>
>     >> Proposal 2: After a suitable period of discussion on the
>     libraries list, >> the Core Libraries Committee will summarize the
>     arguments for and >>
>     against a proposal and post it, along with a (justified)
>     preliminary >>
>     decision, to a low-traffic, announce-only email list. After another >>
>     suitable period of discussion, they will issue a final decision.
>     What is
>     >> a suitable period of time? Perhaps that depends on the
>     properties of
>     the >> proposal, such as whether it breaks backwards
>     compatibility. > >
>     That generally sounds like a good compromise, if this actually helps >
>     reaching the otherwise unreachable parts of the community and have
>     their
>     > voices heard.
>
>     My hope is that a low-volume mailing list would indeed reach a wider
>     audience.
>
>     >> Proposal 3: A decision regarding any proposal that
>     significantly affects >> backwards compatibility is within the
>     purview of the Haskell Prime
>     >> Committee, not the Core Libraries Committee. > > I don't see
>     how that
>     would change much. The prior Haskell Prime > Committee has been
>     traditionally self-elected as well. So it's just the > label of the
>     committee you'd swap out. > > In the recent call of nominations[1] for
>     Haskell Prime, the stated area > of work for the new nominations
>     was to
>     take care of the *language* part, > because that's what we are lacking
>     the workforce for. > > Since its creation for the very purpose of
>     watching over the core > libraries, the core-libraries-committee has
>     been almost exclusively busy > with evaluating and deciding about
>     changes to the `base` library and > overseeing their implementation.
>     Transferring this huge workload to the > new Haskell Prime committee
>     members who have already their hands full > with revising the language
>     part would IMO just achieve to reduce the > effectiveness of the
>     upcoming Haskell Prime committee, and therefore > increase the risk of
>     failure in producing an adequate new Haskell Report > revision.
>
>     My understanding is that much of the work of the core libraries
>     committee does not "significantly affect backwards compatibility," at
>     least not to the extent that MRP does. If this is the case, the
>     bulk of
>     their workload would not be transferred to the new Haskell Prime
>     committee. Is my understanding incorrect?
>
>     The intent of Proposal 3 was to transfer only a small fraction of the
>     issues that come before the core libraries committee to the Haskell
>     Prime committee. In any case, we would certainly need to clarify what
>     "significantly affects backwards compatibility" means.
>
>     Perhaps we should consider direct elections for the Haskell Prime
>     committee as well as changing their mandate to include some subset of
>     the changes proposed to libraries covered by the Haskell Report. My
>     understanding of the current state of affairs is that the Haskell
>     Prime
>     committee is charged with producing a new report, but the core
>     libraries
>     committee is in charge of the library part of that report. Is that
>     correct?
>
>     Cheers,
>     Geoff
>
>     > Regards, >   H.V.Riedel > >  [1]:
>     https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>     >  [2]:
>     https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html
>
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Dan Doel
In reply to this post by Geoffrey Mainland
Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
only for myself). As I recall, one of the reasons I got tapped for it
was due to my having some historical knowledge about Haskell; not
because I was there, but because I've gone back and looked at some old
reports and whatnot (and sometimes think they're better than what we
have now).

But, I was around (of course) when the core libraries committee
started up, so perhaps I can play the role of historian for this as
well.

The reason the committee exists is because a couple years ago, people
brought up the ideas that were finally realized in the
Applicative-Monad proposal and the Foldable-Traversable proposal. A
lot of people weighed in saying they thought they were a good idea,
and significantly fewer people weighed in saying they thought that it
shouldn't happen for various reasons---roughly the same things that
people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was
widely agreed among most users that Functor should be a superclass of
Monad since I started learning Haskell around 10 years ago. And once
Applicative was introduced, it was agreed that that should go in the
middle of the two. But it appeared that it would never happen, despite
a significant majority thinking it should, because no one wanted to do
anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of
people even use Haskell/GHC anymore? Why shouldn't they start using
some other language that will let them change 15-year-old mistakes, or
adapt to ideas that weren't even available at that time (but are still
fairly old and established, all things considered). And the answer was
that there should be some body empowered to decide to move forward
with these ideas, even if there is some dissent. And frankly, it
wasn't going to be the prime committee, because it hadn't shown any
activity in something like 3 years at the time, and even when it was
active, it didn't make anywhere near the sort of changes that were
being discussed.

And the kicker to me is, many things that people are complaining about
again (e.g. the FTP) were the very things that the committee was
established to execute. I don't think we had a formal vote on that
proposal, because we didn't need to. Our existence was in part to
execute that proposal (and AMP). And then a year ago, when it was
finally time to release the changes, there was another ruckus. And we
still didn't have a CLC vote on the matter. What we did was conduct a
community poll, and then SPJ reviewed the submissions. But I don't
mean to pass the buck to him, because I'm pretty sure he was worried
that we were crazy, and overstepping our bounds. Just, the results of
the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core
libraries committee is unsound, and making bad decisions. But the
complaints are mostly not even about actual decisions we made (aside
from maybe Lennart Augustsson's, where he is unhappy with details of
the FTP that you can blame on us, but were designed to break the least
code, instead of being the most elegant; if we had pleased him more,
we would have pleased others less). They are about the reasons for
founding the committee in the first place. You can blame us, if you
like, because I think it's certain that we would have approved them if
we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should
have been deferred to a Haskell Prime committee mean, to me, that the
hope is that they would have been rejected. That the Haskell Prime
committee should have just vetoed these proposals that something like
80% or more of practicing Haskell users (as far as we can tell) wanted
for years before they finally happened. That the Haskell Prime
committee should be responsible for enforcing the very status quo that
led to the CLC in the first place, where proposals with broad support
but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier
question: why should most of these people stick around to obey by the
Haskell Prime committee's pronouncements, instead of getting to work
on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the
complaints are. We try to accomplish the (large) changes in a manner
that allows transition via refactoring over multiple versions (and as
I mentioned earlier, some complaints are that we compromised _too
much_ for this). And in light of the more recent complaints, it's even
been decided that our time frames should be longer. Rolling up changes
into a report just seems like it makes transitions less smooth. Unless
the idea is to make GHC capable of switching out entire base library
sets; but someone has to implement that, and once you have it, it
makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers,
-- Dan

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
<[hidden email]> wrote:

> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>> Friends
>>
>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>>
>> |  Proposal 2: After a suitable period of discussion on the libraries list, the
>> |  Core Libraries Committee will summarize the arguments for and against a
>> |  proposal and post it, along with a (justified) preliminary decision, to a
>> |  low-traffic, announce-only email list. After another suitable period of
>> |  discussion, they will issue a final decision. What is a suitable period of
>> |  time? Perhaps that depends on the properties of the proposal, such as
>> |  whether it breaks backwards compatibility.
>>
>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>>
>> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
>> |  the right thing.
>>
>> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>>
>> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>>
>>  * transparency;
>>  * clarity about what decisions are on the table;
>>  * broad consultation about decisions that affect
>>     a broad constituency; and
>>  * a decent opportunity to debate them without having
>>     to be involved in massive email threads.  Let's try do to that.
>>
>> Simon
>>
>> PS: For what it's worth I'm less keen on Geoff's other proposal:
>>
>> |  Proposal 3: A decision regarding any proposal that significantly affects
>> |  backwards compatibility is within the purview of the Haskell Prime
>> |  Committee, not the Core Libraries Committee.
>>
>> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
>
> For the record, I am also not sure Proposal 3 is a good idea :)
>
> However, I do think we could clarify what the respective
> responsibilities of the core libraries committee and Haskell Prime
> committees are.
>
> One possible choice is that the core libraries committee is responsible
> for changes to the core libraries that do not affect libraries in the
> report. It is meant to be nimble, able to quickly deal with the large
> volume of library changes that do not impact backwards compatibility.
>
> In this scenario, the Haskell Prime committee, using a longer
> deliberative process, would consider the more impactful library changes
> and batch them up into new reports.
>
> You are absolutely correct that moving the question to the Haskell Prime
> committee risks pushing the issue around. The idea behind the separation
> outlined above is to reduce the treadmill; the two bodies use different
> processes, with different time frames, to arrive at decisions. Some
> library decisions may deserve a longer deliberative process.
>
> Cheers,
> Geoff
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Breaking Changes and Long Term Support Haskell

Carter Schonwald
Well said!

I do have a small worry that the longer roll out window will be harder to manage given that every thing is done by (outstanding) volunteers.  But maybe the answer there is that ghc should do major version releases more frequently :), eg every 9 months instead of every 12! 😀

On Wednesday, October 21, 2015, Dan Doel <[hidden email]> wrote:
Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
only for myself). As I recall, one of the reasons I got tapped for it
was due to my having some historical knowledge about Haskell; not
because I was there, but because I've gone back and looked at some old
reports and whatnot (and sometimes think they're better than what we
have now).

But, I was around (of course) when the core libraries committee
started up, so perhaps I can play the role of historian for this as
well.

The reason the committee exists is because a couple years ago, people
brought up the ideas that were finally realized in the
Applicative-Monad proposal and the Foldable-Traversable proposal. A
lot of people weighed in saying they thought they were a good idea,
and significantly fewer people weighed in saying they thought that it
shouldn't happen for various reasons---roughly the same things that
people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was
widely agreed among most users that Functor should be a superclass of
Monad since I started learning Haskell around 10 years ago. And once
Applicative was introduced, it was agreed that that should go in the
middle of the two. But it appeared that it would never happen, despite
a significant majority thinking it should, because no one wanted to do
anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of
people even use Haskell/GHC anymore? Why shouldn't they start using
some other language that will let them change 15-year-old mistakes, or
adapt to ideas that weren't even available at that time (but are still
fairly old and established, all things considered). And the answer was
that there should be some body empowered to decide to move forward
with these ideas, even if there is some dissent. And frankly, it
wasn't going to be the prime committee, because it hadn't shown any
activity in something like 3 years at the time, and even when it was
active, it didn't make anywhere near the sort of changes that were
being discussed.

And the kicker to me is, many things that people are complaining about
again (e.g. the FTP) were the very things that the committee was
established to execute. I don't think we had a formal vote on that
proposal, because we didn't need to. Our existence was in part to
execute that proposal (and AMP). And then a year ago, when it was
finally time to release the changes, there was another ruckus. And we
still didn't have a CLC vote on the matter. What we did was conduct a
community poll, and then SPJ reviewed the submissions. But I don't
mean to pass the buck to him, because I'm pretty sure he was worried
that we were crazy, and overstepping our bounds. Just, the results of
the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core
libraries committee is unsound, and making bad decisions. But the
complaints are mostly not even about actual decisions we made (aside
from maybe Lennart Augustsson's, where he is unhappy with details of
the FTP that you can blame on us, but were designed to break the least
code, instead of being the most elegant; if we had pleased him more,
we would have pleased others less). They are about the reasons for
founding the committee in the first place. You can blame us, if you
like, because I think it's certain that we would have approved them if
we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should
have been deferred to a Haskell Prime committee mean, to me, that the
hope is that they would have been rejected. That the Haskell Prime
committee should have just vetoed these proposals that something like
80% or more of practicing Haskell users (as far as we can tell) wanted
for years before they finally happened. That the Haskell Prime
committee should be responsible for enforcing the very status quo that
led to the CLC in the first place, where proposals with broad support
but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier
question: why should most of these people stick around to obey by the
Haskell Prime committee's pronouncements, instead of getting to work
on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the
complaints are. We try to accomplish the (large) changes in a manner
that allows transition via refactoring over multiple versions (and as
I mentioned earlier, some complaints are that we compromised _too
much_ for this). And in light of the more recent complaints, it's even
been decided that our time frames should be longer. Rolling up changes
into a report just seems like it makes transitions less smooth. Unless
the idea is to make GHC capable of switching out entire base library
sets; but someone has to implement that, and once you have it, it
makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers,
-- Dan

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
<<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mainland@apeiron.net&#39;)">mainland@...> wrote:
> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
>> Friends
>>
>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future.  Geoff's message had some good ideas, especially this bit:
>>
>> |  Proposal 2: After a suitable period of discussion on the libraries list, the
>> |  Core Libraries Committee will summarize the arguments for and against a
>> |  proposal and post it, along with a (justified) preliminary decision, to a
>> |  low-traffic, announce-only email list. After another suitable period of
>> |  discussion, they will issue a final decision. What is a suitable period of
>> |  time? Perhaps that depends on the properties of the proposal, such as
>> |  whether it breaks backwards compatibility.
>>
>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing.  I believe that the Core Libraries committee is thinking actively about this.
>>
>> |  Personally, I think AMP was the right thing to do, but I don't think FTP was
>> |  the right thing.
>>
>> These make good examples to motivate future changes to our process.  But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above.  We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction.  In a big community, even a broad consultation may yield a result that some think is ill-advised.  That's part of the joyful burden of being a big community.
>>
>> Let's look forward, not back.  I think we can do better in future than we have done in the past.  I don't think we can hope for unanimity, but I think we can reasonably seek
>>
>>  * transparency;
>>  * clarity about what decisions are on the table;
>>  * broad consultation about decisions that affect
>>     a broad constituency; and
>>  * a decent opportunity to debate them without having
>>     to be involved in massive email threads.  Let's try do to that.
>>
>> Simon
>>
>> PS: For what it's worth I'm less keen on Geoff's other proposal:
>>
>> |  Proposal 3: A decision regarding any proposal that significantly affects
>> |  backwards compatibility is within the purview of the Haskell Prime
>> |  Committee, not the Core Libraries Committee.
>>
>> *Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.
>
> For the record, I am also not sure Proposal 3 is a good idea :)
>
> However, I do think we could clarify what the respective
> responsibilities of the core libraries committee and Haskell Prime
> committees are.
>
> One possible choice is that the core libraries committee is responsible
> for changes to the core libraries that do not affect libraries in the
> report. It is meant to be nimble, able to quickly deal with the large
> volume of library changes that do not impact backwards compatibility.
>
> In this scenario, the Haskell Prime committee, using a longer
> deliberative process, would consider the more impactful library changes
> and batch them up into new reports.
>
> You are absolutely correct that moving the question to the Haskell Prime
> committee risks pushing the issue around. The idea behind the separation
> outlined above is to reduce the treadmill; the two bodies use different
> processes, with different time frames, to arrive at decisions. Some
> library decisions may deserve a longer deliberative process.
>
> Cheers,
> Geoff
> _______________________________________________
> Libraries mailing list
> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Libraries@haskell.org&#39;)">Libraries@...
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Haskell-prime mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Haskell-prime@haskell.org&#39;)">Haskell-prime@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Simon Peyton Jones
In reply to this post by Dan Doel
While we are here, let me say

  A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE

Library design has a lot of detail, and a lot of competing priorities.  I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time.

Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done.  So we are far far further on than before.

Still not perfect, as my last post said. But still: THANK YOU.

Simon

| -----Original Message-----
| From: Dan Doel [mailto:[hidden email]]
| Sent: 21 October 2015 22:23
| To: Geoffrey Mainland
| Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
| [hidden email] List; Haskell Libraries
| Subject: Re: Breaking Changes and Long Term Support Haskell
|
| Hello,
|
| I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
| only for myself). As I recall, one of the reasons I got tapped for it
| was due to my having some historical knowledge about Haskell; not
| because I was there, but because I've gone back and looked at some old
| reports and whatnot (and sometimes think they're better than what we
| have now).
|
| But, I was around (of course) when the core libraries committee
| started up, so perhaps I can play the role of historian for this as
| well.
|
| The reason the committee exists is because a couple years ago, people
| brought up the ideas that were finally realized in the
| Applicative-Monad proposal and the Foldable-Traversable proposal. A
| lot of people weighed in saying they thought they were a good idea,
| and significantly fewer people weighed in saying they thought that it
| shouldn't happen for various reasons---roughly the same things that
| people are still bringing up about these proposals.
|
| This wasn't the first time that happened, either. I think it was
| widely agreed among most users that Functor should be a superclass of
| Monad since I started learning Haskell around 10 years ago. And once
| Applicative was introduced, it was agreed that that should go in the
| middle of the two. But it appeared that it would never happen, despite
| a significant majority thinking it should, because no one wanted to do
| anything without pretty much unanimous consent.
|
| So, one question that got raised is: why should this majority of
| people even use Haskell/GHC anymore? Why shouldn't they start using
| some other language that will let them change 15-year-old mistakes, or
| adapt to ideas that weren't even available at that time (but are still
| fairly old and established, all things considered). And the answer was
| that there should be some body empowered to decide to move forward
| with these ideas, even if there is some dissent. And frankly, it
| wasn't going to be the prime committee, because it hadn't shown any
| activity in something like 3 years at the time, and even when it was
| active, it didn't make anywhere near the sort of changes that were
| being discussed.
|
| And the kicker to me is, many things that people are complaining about
| again (e.g. the FTP) were the very things that the committee was
| established to execute. I don't think we had a formal vote on that
| proposal, because we didn't need to. Our existence was in part to
| execute that proposal (and AMP). And then a year ago, when it was
| finally time to release the changes, there was another ruckus. And we
| still didn't have a CLC vote on the matter. What we did was conduct a
| community poll, and then SPJ reviewed the submissions. But I don't
| mean to pass the buck to him, because I'm pretty sure he was worried
| that we were crazy, and overstepping our bounds. Just, the results of
| the survey were sufficient for him to not overrule us.
|
| So my point is this: there seems to be some sentiment that the core
| libraries committee is unsound, and making bad decisions. But the
| complaints are mostly not even about actual decisions we made (aside
| from maybe Lennart Augustsson's, where he is unhappy with details of
| the FTP that you can blame on us, but were designed to break the least
| code, instead of being the most elegant; if we had pleased him more,
| we would have pleased others less). They are about the reasons for
| founding the committee in the first place. You can blame us, if you
| like, because I think it's certain that we would have approved them if
| we had formally voted. We just didn't even need to do so.
|
| Forgive me if I'm wrong, but suggestions that these decisions should
| have been deferred to a Haskell Prime committee mean, to me, that the
| hope is that they would have been rejected. That the Haskell Prime
| committee should have just vetoed these proposals that something like
| 80% or more of practicing Haskell users (as far as we can tell) wanted
| for years before they finally happened. That the Haskell Prime
| committee should be responsible for enforcing the very status quo that
| led to the CLC in the first place, where proposals with broad support
| but minority dissent never pass for various core modules.
|
| If this is the case, then one could simply repose the earlier
| question: why should most of these people stick around to obey by the
| Haskell Prime committee's pronouncements, instead of getting to work
| on a language that incorporates their input?
|
| And if it isn't, then I don't ultimately understand what the
| complaints are. We try to accomplish the (large) changes in a manner
| that allows transition via refactoring over multiple versions (and as
| I mentioned earlier, some complaints are that we compromised _too
| much_ for this). And in light of the more recent complaints, it's even
| been decided that our time frames should be longer. Rolling up changes
| into a report just seems like it makes transitions less smooth. Unless
| the idea is to make GHC capable of switching out entire base library
| sets; but someone has to implement that, and once you have it, it
| makes the report specifications _less_ essential.
|
| Anyhow, that's my history lesson. Take it as you (all) will.
|
| Cheers,
| -- Dan
|
| On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland
| <[hidden email]> wrote:
| > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:
| >> Friends
| >>
| >> I think it's good for us to debate the question of how we should
| balance innovation against change; and how we should make those decisions
| in future.  Geoff's message had some good ideas, especially this bit:
| >>
| >> |  Proposal 2: After a suitable period of discussion on the libraries
| list, the
| >> |  Core Libraries Committee will summarize the arguments for and
| against a
| >> |  proposal and post it, along with a (justified) preliminary decision,
| to a
| >> |  low-traffic, announce-only email list. After another suitable period
| of
| >> |  discussion, they will issue a final decision. What is a suitable
| period of
| >> |  time? Perhaps that depends on the properties of the proposal, such
| as
| >> |  whether it breaks backwards compatibility.
| >>
| >> Identifying major changes to the libraries, and having a better
| publicised, more RFC-like process for deliberating them, would be a good
| thing.  I believe that the Core Libraries committee is thinking actively
| about this.
| >>
| >> |  Personally, I think AMP was the right thing to do, but I don't think
| FTP was
| >> |  the right thing.
| >>
| >> These make good examples to motivate future changes to our process.
| But in the end FTP was subject to a pretty broad deliberative process,
| precisely along the lines that Geoff suggests above.  We had two clearly-
| articulated alternatives, a discrete call for opinions broadcast to every
| Haskell channel we could find, a decent interval for people to respond,
| and (as it turned out) a very clear preponderance of opinion in one
| direction.  In a big community, even a broad consultation may yield a
| result that some think is ill-advised.  That's part of the joyful burden
| of being a big community.
| >>
| >> Let's look forward, not back.  I think we can do better in future than
| we have done in the past.  I don't think we can hope for unanimity, but I
| think we can reasonably seek
| >>
| >>  * transparency;
| >>  * clarity about what decisions are on the table;
| >>  * broad consultation about decisions that affect
| >>     a broad constituency; and
| >>  * a decent opportunity to debate them without having
| >>     to be involved in massive email threads.  Let's try do to that.
| >>
| >> Simon
| >>
| >> PS: For what it's worth I'm less keen on Geoff's other proposal:
| >>
| >> |  Proposal 3: A decision regarding any proposal that significantly
| affects
| >> |  backwards compatibility is within the purview of the Haskell Prime
| >> |  Committee, not the Core Libraries Committee.
| >>
| >> *Precisely* the same issues will arise whether it's CLC or HPC.  And
| the HPC is going to be jolly busy with language issues. Moving the
| question from one group to another risks avoiding the issue rather than
| addressing it.
| >
| > For the record, I am also not sure Proposal 3 is a good idea :)
| >
| > However, I do think we could clarify what the respective
| > responsibilities of the core libraries committee and Haskell Prime
| > committees are.
| >
| > One possible choice is that the core libraries committee is responsible
| > for changes to the core libraries that do not affect libraries in the
| > report. It is meant to be nimble, able to quickly deal with the large
| > volume of library changes that do not impact backwards compatibility.
| >
| > In this scenario, the Haskell Prime committee, using a longer
| > deliberative process, would consider the more impactful library changes
| > and batch them up into new reports.
| >
| > You are absolutely correct that moving the question to the Haskell Prime
| > committee risks pushing the issue around. The idea behind the separation
| > outlined above is to reduce the treadmill; the two bodies use different
| > processes, with different time frames, to arrive at decisions. Some
| > library decisions may deserve a longer deliberative process.
| >
| > Cheers,
| > Geoff
| > _______________________________________________
| > Libraries mailing list
| > [hidden email]
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
| ll.org%2fcgi-
| bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic
| rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0
| 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Breaking Changes and Long Term Support Haskell

Simon Peyton Jones
In reply to this post by Geoffrey Mainland
| For the record, I am also not sure Proposal 3 is a good idea :)
|
| However, I do think we could clarify what the respective
| responsibilities of the core libraries committee and Haskell Prime
| committees are.

My instinct is this:
  Haskell Prime: language
  Core Libraries Committee: libraries

That seems simple.  If we try to move the largest and most challenging library design tasks from CLC to HP, I fear that we will overload the latter and devalue the former.

| You are absolutely correct that moving the question to the Haskell Prime
| committee risks pushing the issue around. The idea behind the separation
| outlined above is to reduce the treadmill; the two bodies use different
| processes, with different time frames, to arrive at decisions. Some
| library decisions may deserve a longer deliberative process.

I do agree that some library changes are far-reaching, and need a more deliberative process.  I think the CLC is in the process of developing such a process.  Moreover, I trust them to be able to tell the difference between low-impact and high-impact changes.

That said, as HP moves towards a new language Report, it would be good if CLC similarly moved towards a new libraries Report, so that there was a single unified document, just as we have had to date.

Simon


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
1 ... 78910111213