Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Henrik Nilsson]

Hi all,

Geoffrey Mainland wrote;

> What worries me most is that we have started to see very valuable
> members of our community publicly state that they are reducing their
> community involvement.

That worries me too. A lot. To quote myself from an earlier
e-mail in this thread:

> Therefore, please let us defer further discussion and
> ultimate decision on MRP to the resurrected
> HaskellPrime committee, which is where it properly
> belongs. Otherwise, the Haskell community itself might
> be one of the things that MRP breaks.

Geoffrey further wrote:

> 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 thus definitely support this, at least for anything related to
the libraries covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively
follow the libraries discussions did so because they simply did not
think that changes to the central libraries as defined in the Haskell
report, at least not breaking changes, were in the remit of the
libraries committee, and were happy to leave discussions on any
other libraries to the users of those libraries. And as a consequence
they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers,
books, what people have learned, or even the community itself, it is
time to very carefully think about what the appropriate processes
should be for going forward.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 


Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Augustsson, Lennart]

I'd say, of course, libraries covered by the Haskell report are not in the 
remit of the libraries committee.

-Original Message-
From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf Of Henrik 
Nilsson
Sent: 21 October 2015 09:25
To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B
Cc: henrik.nils...@nottingham.ac.uk; haskell-prime@haskell.org List; Graham 
Hutton; Haskell Libraries; haskell cafe
Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving 
`return` out of `Monad`

Hi all,

Geoffrey Mainland wrote;

 > What worries me most is that we have started to see very valuable  > members 
 > of our community publicly state that they are reducing their  > community 
 > involvement.

That worries me too. A lot. To quote myself from an earlier e-mail in this 
thread:

 > Therefore, please let us defer further discussion and  > ultimate decision 
 > on MRP to the resurrected  > HaskellPrime committee, which is where it 
 > properly  > belongs. Otherwise, the Haskell community itself might  > be one 
 > of the things that MRP breaks.

Geoffrey further wrote:

 > 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 thus definitely support this, at least for anything related to the libraries 
covered by the Haskell report.

Indeed, I strongly suspect that many people who did not actively follow the 
libraries discussions did so because they simply did not think that changes to 
the central libraries as defined in the Haskell report, at least not breaking 
changes, were in the remit of the libraries committee, and were happy to leave 
discussions on any other libraries to the users of those libraries. And as a 
consequence they were taken by surprise by AMP etc.

So before breaking anything more, that being code, research papers, books, what 
people have learned, or even the community itself, it is time to very carefully 
think about what the appropriate processes should be for going forward.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

___
Libraries mailing list
librar...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market 
commentary has been prepared by sales and/or trading desk of Standard Chartered 
Bank or its affiliate. It is not and does not constitute research material, 
independent research, recommendation or financial advice. Any market commentary 
is for information purpose only and shall not be relied for any other purpose, 
and is subject to the relevant disclaimers available at 
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign on the term 
sheet to acknowledge in respect of the same.

Please visit 
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
 for important information with respect to derivative products.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Henrik Nilsson]

Hi all,

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.

Speaking for myself, I have had to clarify this position a number
of times now, as there has been a tendency by the some proponents of
the proposed changes to suggest that those who disagree are against
all changes, the long term implication being that Haskell would
"stagnate and die".

And in the light of the above, I felt compelled to clarify this
position again.

It's not about no more changes ever. It is about ensuring that
changes are truly worthwhile and have wide support.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 


Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Breaking Changes and Long Term Support Haskell

[Augustsson, Lennart]

I'd like to vehemently agree with Henrik here. :)

Personally, I think AMP was the right thing to do, but I don't think FTP was 
the right thing.
And I don't think changes that break code are necessarily bad either, just some 
of them.

(To clarify, I'm against the Foldable class, but not Traversable.  It would 
have been quite feasible to have the latter, but not the former.)

  -- Lennart


-Original Message-
From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf Of 
Henrik Nilsson
Sent: 21 October 2015 11:17
To: haskell-prime@haskell.org List; Haskell Libraries
Subject: Re: Breaking Changes and Long Term Support Haskell

Hi all,

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.

Speaking for myself, I have had to clarify this position a number of times now, 
as there has been a tendency by the some proponents of the proposed changes to 
suggest that those who disagree are against all changes, the long term 
implication being that Haskell would "stagnate and die".

And in the light of the above, I felt compelled to clarify this position again.

It's not about no more changes ever. It is about ensuring that changes are 
truly worthwhile and have wide support.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This email and any attachments are confidential and may also be privileged. If 
you are not the intended recipient, please delete all copies and notify the 
sender immediately. You may wish to refer to the incorporation details of 
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market 
commentary has been prepared by sales and/or trading desk of Standard Chartered 
Bank or its affiliate. It is not and does not constitute research material, 
independent research, recommendation or financial advice. Any market commentary 
is for information purpose only and shall not be relied for any other purpose, 
and is subject to the relevant disclaimers available at 
http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by 
responding affirmatively to this e-mail, you agree that you have understood the 
terms and conditions in the attached term sheet and evaluated the merits and 
risks of the transaction. We may at times also request you to sign on the term 
sheet to acknowledge in respect of the same.

Please visit 
http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
 for important information with respect to derivative products.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Herbert Valerio Riedel]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Committee M.O. Change Proposals

[Geoffrey Mainland]

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 c

Re: Committee M.O. Change Proposals

[Geoffrey Mainland]

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 t

Re: Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

[Edward Kmett]

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 
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 

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  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
> mailto:mainl...@apeiron.net>> 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

Re: Breaking Changes and Long Term Support Haskell

[Dan Doel]

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

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  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) change

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

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:dan.d...@gmail.com]
| Sent: 21 October 2015 22:23
| To: Geoffrey Mainland
| Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
| pr...@haskell.org 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 prop

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

| 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


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

Hi Dan,

Thank you for the historical perspective.

I was careful not to criticize the committee. Instead, I made three
concrete proposals with the hope that they would help orient a conversation.

It sounds like you are not for proposal 3. How about the other two?

My original email stated my underlying concern: we are losing valuable
members of the community not because of the technical decisions that are
being made, but because of the process by which they are being made.
That concern is what drove my proposals. It is perfectly valid to think
that that loss was the inevitable price of progress, but that is not my
view.

Cheers,
Geoff

On 10/21/15 5:22 PM, Dan Doel 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

Re: Breaking Changes and Long Term Support Haskell

[Henrik Nilsson]

Hi Dan,

Thanks for the history lesson. You do make many valid points.
And I also want to say thank you for the hard work that CLC
has put in.

Let me nevertheless react to a handful of things:

> 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.

I have seen criticism of the Haskell committee along similar lines
before, but I think it is overly simplistic, and arguably unfair,
for two reasons. First, squarely measuring accomplishment in terms
of number or scope of changes, which seems to be the gist (apologies
if I misunderstand), is, frankly, naive. In many ways, what didn't
change, for example, can be at least as important as what did for
establishing a language as a viable and attractive proposition for
large scale work. And the value of that for a language community as a
whole is hard to overstate. Now, I have no real data to back up that the
committee achieved that. But it is clear that Haskell has grown
a lot over the past 5 to 10 years, i.e. well before AMP, FTP, etc.
So maybe the last instance of the Haskell committee actually achieved
a great deal more than some seem willing to give it credit for.

Secondly, let us not forget that at least one highly controversial
and very breaking change was adopted for Haskell 2010: dropping
n + k patterns. The reason that went through was that there were very
compelling technical reasons and ultimately a clear case for
the advantages outweighing the disadvantages by a wide margin. So it is
not as if a committee cannot make controversial decisions. That does
presuppose that the majority of its members fundamentally have the 
interest of the community at large at the fore, and are willing to take

good arguments aboard, rather than being prone to take stances mainly
for "political" reasons. Fortunately, I strongly believe the Haskell
community by and large is rational in this sense.

> 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.

OK, you are forgiven! I can of course only speak for myself, but I have
followed this discussion very carefully, and discussed with many people
in person. And as far as I can tell, there is absolutely nothing to
suggest that the reason that those who are unhappy with the process by
which AMP, FTP etc. happened (or by some of the details of those
proposals)  raise the possibility that the Haskell committee in one way
or another should have been (or in the future be) involved at least as
a vetting instance when it comes to the most far-reaching library
changes, is a secret hope of "death by committee".

Anyway, whether there are one or two committees ultimately does not
really matter, as long as both are widely seen to have a wide mandate
for whatever they are entrusted with, and as long as the process for
far-reaching changes is sufficiently robust and long.

> 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.

Now, I have no desire to diminish the significance of the outcome of
that poll. Nor have I any desire to be branded as an "anti-democrat".
But if I am, so be it: I am bracing myself.

However, I have to point out that there is a lot more to
well-functioning democracies than simple majority votes. Look at any
developed democracy and there are lots of checks and balances in place
to safe-guard the interests of an as broad part of the population as
possible. In a federated state, just to give one example, there is
often a bicameral parliament where the states (broadly) have equal say
in one of the chambers irrespective of their size.

And yes, the workings of democracies are slow, sometimes painfully
so, but fundamentally that is for good reason.

To return to the case of a programming language community,
it is pretty much by definition going to be the case that a small
part of that community will be hit disproportionately hard by
changes to the language and/or its core libraries.

Their interests need to be adequately safeguarded too, or they will
surely jump ship in search of high and dry ground rather than run the
risk of drowning in the next wave of changes.

This, to the best of my understanding, is where I and others who
are suggesting that far-reaching changes should go past a
committee with a clear mandate and a sufficiently robust and long
process are coming from.

And I believe this is also what underlies Lennart's sentiment:

> I think voting to decide these kind of issues a terrible idea; we
> migh

Re: Breaking Changes and Long Term Support Haskell

[Tony Morris]

Thanks Dan and others on CLC for your hard work and endurance.


On 22/10/15 07:48, Simon Peyton Jones wrote:
> 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:dan.d...@gmail.com]
> | Sent: 21 October 2015 22:23
> | To: Geoffrey Mainland
> | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
> | pr...@haskell.org 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 

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[John Wiegley]

> Henrik Nilsson  writes:

> So before breaking anything more, that being code, research papers, books,
> what people have learned, or even the community itself, it is time to very
> carefully think about what the appropriate processes should be for going
> forward.

Hi Henrik,

I'd really like to understand your position better, since I'm pretty sure it's
not just a juxtaposition between "change" or "no change".

How would you like to see Haskell grow in the future? What does a successful
process to evolve the language look like to you? Is it the change causing you
difficulty, or the way we arrive at the change?

John
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Dan Doel]

For proposal 3, I don't see what difference it makes whether a
refreshed Haskell committee or a new libraries committee makes
decisions that affect backwards compatibility. A name doesn't ensure
good decision making. The only difference I can see is that the
Haskell committee might only publish final decisions every couple
years. But the Haskell report also isn't designed to describe
migration plans between feature revisions; unless the plan is to start
incorporating library deprecation and whatnot into the report (which
would be odd to me). But that would just be doing the same thing
slower, so it'd be little different than making library changes over 6
to 9 GHC versions instead of 3.

For proposal 2, I don't know how effective it will be in practice. I
believe it is already the job of a proposal submitter to summarize the
arguments made about it, according to the library proposal guidelines.
We could post those summaries to another list. But unless more people
promise they will be diligent about reading that list, I'm not sure
that one factor in these dust ups (surprise) will actually be any
different.

Also, if amount of discussion is at issue, I'm not sure I agree. For
AMP, I was waiting a decade, more or less. I thought we should do it,
other people thought we shouldn't because it would break things. I
don't know what more there was to discuss, except there was more stuff
to break the longer we waited.

As for FTP, some aspects only became known as the proposal was
implemented, and I don't know that they would have been realized
regardless of how long the proposal were discussed. And then we still
had a month or so of discussion after the implementation was
finalized, on the cusp of GHC 7.10 being released. So how much more
_was_ needed, that people are now discussing it again?

If it's just about documenting more things, there's certainly no harm in that.

For 1, I don't have a very strong opinion. If pressed, I would
probably express some similar sentiments to Henrik. I certainly don't
think Haskell would be nearly as good as it is if it were a simple
majority vote by all users (and I probably wouldn't use it if that's
how things were decided). Would a community vote for libraries
committee be better than appointment by people who previously held the
power (but have more to do than any human can accomplish)? I don't
know.

I should say, though, that things are not now run by simple majority
vote. What we conducted a year ago was a survey, where people
submitted their thoughts. I didn't get to read them, because they were
private, and it wasn't my decision to make. But it was not just +80
-20.

With regard to your last paragraph, unless I've missed something (and
I confess that I haven't read every comment in these threads), the
recent resignations didn't express disagreement with the decision
making process. They expressed disagreement with the (technical)
decisions (and their effects). I don't see how a different process
could have solved that unless it is expected that it would have made
different decisions.

-- Dan

On Wed, Oct 21, 2015 at 6:18 PM, Geoffrey Mainland  wrote:
> Hi Dan,
>
> Thank you for the historical perspective.
>
> I was careful not to criticize the committee. Instead, I made three
> concrete proposals with the hope that they would help orient a conversation.
>
> It sounds like you are not for proposal 3. How about the other two?
>
> My original email stated my underlying concern: we are losing valuable
> members of the community not because of the technical decisions that are
> being made, but because of the process by which they are being made.
> That concern is what drove my proposals. It is perfectly valid to think
> that that loss was the inevitable price of progress, but that is not my
> view.
>
> Cheers,
> Geoff
>
> On 10/21/15 5:22 PM, Dan Doel 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

Re: Breaking Changes and Long Term Support Haskell

[Taru Karttunen]

On 21.10 17:42, Gregory Collins wrote:
> All I'm saying is that if we want to appeal to or cater to working software
> engineers, we have to be a lot less cavalier about causing more work for
> them, and we need to prize stability of the core infrastructure more
> highly. That'd be a broader cultural change, and that goes beyond process:
> it's policy.

I think that how the changes are handled can make a large difference.

E.g. if

A) Most of Hackage (including dependencies) compiles with new GHC.
(stack & stackage helps somewhat)

B) There is an automated tool that can be used to fix most code
to compile with new versions of GHC without warnings or CPP.

C) Hackage displays vocally what works with which versions of
GHC (Status reports do help somewhat)

Then I think much of the complaints would go away.

- Taru Karttunen
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen  wrote:

> E.g. if
>
> A) Most of Hackage (including dependencies) compiles with new GHC.
> (stack & stackage helps somewhat)
>
> B) There is an automated tool that can be used to fix most code
> to compile with new versions of GHC without warnings or CPP.
>
> C) Hackage displays vocally what works with which versions of
> GHC (Status reports do help somewhat)
>


> Then I think much of the complaints would go away.


If we had those things, indeed they would!

However, beyond A (GHC 7.10 was tested more extensively against
hackage/stackage than any previous release of Haskell by far!), the others
require various degrees of engineering effort, including some way to deal
with refactoring code that already has CPP in it, more extensive build-bot
services, etc. and those sort of non-trivial artifacts just haven't been
forthcoming. =/

I would be very happy if those things showed up, however.

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins 
wrote:

>
> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland 
> wrote:
>
>> My original email stated my underlying concern: we are losing valuable
>> members of the community not because of the technical decisions that are
>> being made, but because of the process by which they are being made.
>>
> [If] you're doing research you're on the treadmill, almost by definition,
> and you're delighted that we're finally making some rapid progress on
> fixing up some of the longstanding warts.
>
> If you're a practitioner, you are interested in using Haskell for, y'know,
> writing programs. You're probably in one of two camps: you're in "green
> field" mode writing a lot of new code (early stage startups, prototype
> work, etc), or you're maintaining/extending programs you've already written
> that are out "in the field" for you doing useful work. Laura Wingerd calls
> this the "annealing temperature" of software, and I think this is a nice
> metaphor to describe it. How tolerant you are of ecosystem churn depends on
> what your temperature is: and I think it should be obvious to everyone that
> Haskell having "success" for programming work would mean that lots of
> useful and correct programs get written, so everyone who is in the former
> camp will cool over time to join the latter.
>

I've made the point before and I don't really want to belabor it: our de
> facto collective posture towards breaking stuff, especially in the past few
> years, has been extremely permissive, and this alienates people who are
> maintaining working programs.
>

Even among people who purported to be teaching Haskell or using Haskell
today in industry the margin of preference for the concrete FTP proposal
was ~79%. This was considerably higher than I expected in two senses. One:
there were a lot more people who claimed to be in one of those two roles
than I expected by far, and two: their appetite for change was higher than
I expected. I initially expected to see a stronger "academic vs. industry"
split in the poll, but the groups were only distinguishable by a few
percentage point delta, so while I expected roughly the end percentage of
the poll, based on the year prior I'd spent running around the planet to
user group meetings and the like, I expected it mostly because I expected
more hobbyists and less support among industrialists.

>
I'm actually firmly of the belief that the existing committee doesn't
> really have process issues, and in fact, that often it's been pretty
> careful to minimize the impact of the changes it wants to make. As others
> have pointed out, lots of the churn actually comes from platform libraries,
> which are out of the purview of this group.
>

Historically we've had a bit of a split personality on this front. Nothing
that touches the Prelude had changed in 17 years. On the other hand the
platform libraries had maintained a pretty heavy rolling wave of breakage
the entire time I've been around in the community. On a more experimental
feature front, I've lost count of the number of different things we've done
to Typeable or template-haskell.


> All I'm saying is that if we want to appeal to or cater to working
> software engineers, we have to be a lot less cavalier about causing more
> work for them, and we need to prize stability of the core infrastructure
> more highly. That'd be a broader cultural change, and that goes beyond
> process: it's policy.
>

The way things are shaping up, we've had 17 years of rock solid stability,
1 release that incorporated changes that were designed to minimize impact,
to the point that the majority of the objections against them are of the
form where people would prefer that we broke _more_ code, to get a more
sensible state. Going forward, it looks like the next 2 GHC releases will
have basically nothing affecting the Prelude, and there will be another
punctuation in the equilibrium around 8.4 as the next set of changes kicks
in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending
changes, and a pretty strong guarantee from the committee that you should
be able to maintain code with a 3 release window without running afoul of
warnings or needing CPP.

So, out of curiosity, what additional stability policy is it that you seek?

-Edward
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime