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

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

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

Henrik Nilsson-2
In reply to this post by Dan Doel
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
 > might as well throw dice.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]




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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Wiegley-2
In reply to this post by Henrik Nilsson-2
>>>>> Henrik Nilsson <[hidden email]> 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
_______________________________________________
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

Gregory Collins-3
In reply to this post by Geoffrey Mainland

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <[hidden email]> 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.

I disagree. The issue is not process, it's posture: e.g. what do we think the language is for, who are its users, what factors do we take into consideration when making decisions about how to change things (and especially: how do we weight those factors), etc. There are several important constituencies within the Haskell community, and they usually have very different attitudes towards what's relevant to take into consideration when deciding what to do.

For example: Haskell has had great success and wide adoption in academic research within a few fields centred around ICFP, POPL, and the like. We all like a GHC that serves as a testbed for research and sometimes that is going to mean churn. The research world would probably be happiest with a Haskell that evolved quickly and speculatively, and that dispensed with blemishes with savage efficiency: 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. 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.

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.

-- 
Gregory Collins <[hidden email]>

_______________________________________________
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
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 <[hidden email]> 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 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

Taru Karttunen
In reply to this post by Gregory Collins-3
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
_______________________________________________
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

Edward Kmett-2
On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen <[hidden email]> 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

_______________________________________________
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

Edward Kmett-2
In reply to this post by Gregory Collins-3
On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <[hidden email]> wrote:

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <[hidden email]> 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

_______________________________________________
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

Herbert Valerio Riedel
In reply to this post by Taru Karttunen
On 2015-10-22 at 08:04:10 +0200, Taru Karttunen wrote:

[...]

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

Fyi, Alan is currently working on levaraging HaRe[1] in

 https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)

and it's already showing great promise. However, tools like this will
only be able to handle the no-brainer cases, as in general it's a NP
hard problem. But luckily, those boring mechanical refactorings usually
represent the vast majority, and that's the tedious work we want
tooling to assist us most with.


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


I.e. something like

  http://matrix.hackage.haskell.org/package/text

? :-)


 [1]: Btw, here's a recent talk which also mentions the use-case of using
      HaRe to update between Haskell Report revisions or `base` versions:
 
      https://skillsmatter.com/skillscasts/6539-a-new-foundation-for-refactoring-ghc-exactprint
_______________________________________________
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

Taru Karttunen
On 22.10 09:04, Herbert Valerio Riedel wrote:
> Fyi, Alan is currently working on levaraging HaRe[1] in
>
>  https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)
>
> and it's already showing great promise. However, tools like this will
> only be able to handle the no-brainer cases, as in general it's a NP
> hard problem. But luckily, those boring mechanical refactorings usually
> represent the vast majority, and that's the tedious work we want
> tooling to assist us most with.

Yes, getting it 99% there as an automated tool would be enough
for most cases.


> > C) Hackage displays vocally what works with which versions of
> > GHC (Status reports do help somewhat)
>
>
> I.e. something like
>
>   http://matrix.hackage.haskell.org/package/text

Yes! Is there a reason that it is not displayed on
http://hackage.haskell.org/package/text which only
displays a link to Status of a 7.8.3 build?

How many percent of Hackage is built with matrix.h.h.o
and is there a plan to integrate it into Hackage pages?

- Taru Karttunen
_______________________________________________
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

Vincent Hanquez
In reply to this post by Gregory Collins-3


On 22/10/2015 01: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.
Not that I disagree that we need general stability but,

I think it's quite unfair to say that working software engineers are
being pushed away because of the current "instability", and actually I
don't see any proof of such a thing.

Working software engineers have developed methods to deal with change
(or not to deal with it) for decades.
To name a few with Haskell: private hackage, stackage, cabal pinning.
It's also commonly available through stack nowadays.

Also, having worked on multiples different Haskell teams doing
commercial/professional software, compiler/libraries upgrades were never
a concern of the team.
It was always something that can be dealt quickly, painlessly and with a
lot more certitude w.r.t the quality assurance, compared to e.g. dynamic
languages where you don't have any types safety etc..

I can't help but think that you meant "opensource library maintainers"
instead of "working software engineers", which is somewhat a very
different beast.

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

Aloïs Cochard
That is very interesting, I just want to second Vincent because what I have read here initially was the exact opposite of the impression I had online.

From my probably biased point of view, the most visible and vocable persons who are being upset recently about FRP seems to be teachers and academics! Which is I must admit was extremely surprising to me.
Most haskellers I know working in the industry, or on open source libraries, seems to be totally fine with the change (and usually they got aware of it long time ago... when it was discussed).

Like some others have pointed out, it feel to me that it's much more an issue about communication than anything else.

Cheers

On 22 October 2015 at 12:57, Vincent Hanquez <[hidden email]> wrote:


On 22/10/2015 01: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.
Not that I disagree that we need general stability but,

I think it's quite unfair to say that working software engineers are being pushed away because of the current "instability", and actually I don't see any proof of such a thing.

Working software engineers have developed methods to deal with change (or not to deal with it) for decades.
To name a few with Haskell: private hackage, stackage, cabal pinning.
It's also commonly available through stack nowadays.

Also, having worked on multiples different Haskell teams doing commercial/professional software, compiler/libraries upgrades were never a concern of the team.
It was always something that can be dealt quickly, painlessly and with a lot more certitude w.r.t the quality assurance, compared to e.g. dynamic languages where you don't have any types safety etc..

I can't help but think that you meant "opensource library maintainers" instead of "working software engineers", which is somewhat a very different beast.

--
Vincent

_______________________________________________
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

Geoffrey Mainland
In reply to this post by Edward Kmett-2
On 10/22/2015 02:40 AM, Edward Kmett wrote:

> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>     <[hidden email] <mailto:[hidden email]>> 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?

Thanks to you and Dan [1], I now have a greater understanding and
appreciation for where the committee has been coming from. My new
understanding is that the changes that were formalized in AMP, FTP, and
MRP were the basis for the committee's creation. It also seems that
there are more changes in the pipeline that have not yet been made into
proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
"stability" is signaling change as far ahead as possible. The committee
has put a lot of effort into this, which I appreciate! However, as each
of these proposal has come down the pipeline, I never realized that they
were part of a larger master plan.

1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be
compatible with future changes helps mitigate the stability issue.

2) How can I write code that makes use of the Prelude so that it will
work with every new GHC release over the next 3 years? 5 years? For
example, how can I write a Monad instance now, knowing the changes that
are coming, so that the instance will work with every new GHC release
for the next 3 years? 5 years? If the answer is "you can't," then when
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
say I don't know the answer!

Finally, if none of these changes broke Prelude backwards compatibility,
far fewer people would be complaining :) Of course, we can't always make
progress without breaking things, but a more deliberative process might
offer an opportunity to make progress while still preserving backwards
compatibility. Take AMP for example. There were at least two [3] [4]
proposals for preserving backwards compatibility. Investigating them
would have taken time and delayed AMP, yes, but why the rush?

3) Can we have a process that allows more deliberation over, and wider
publicity for, changes that break backwards compatibility? The goal of
such a process would not be to prevent change, but to allow more time to
find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were
announced was meant to provide wider publicity.

Personally, I think these proposals do indeed fix a lot of warts in the
language. As a researcher who uses actively uses Haskell every day,
these warts have had approximately zero impact on me for the past
(almost) decade, and I would be perfectly content if they were never
fixed. The only pain I can recall enduring is having to occasionally
write an orphan Applicative instance. I have been importing Prelude
hiding mapM for years. I have been importing Control.Applicative for
years. Neither has been painful. Dealing with AMP? I'm working on a
collaborative research project that is stuck on 7.8 because of AMP. I
agree, that seems silly, but whether or not it is silly, it is an impact
I feel.

One way to look at these proposals is to ask the question "Wouldn't the
language be nicer if all these changes were made?" Another is to ask the
question "Does the fact that these changes have not been made make your
life as a Haskell programmer more difficult in any significant way?" I
answer "yes" to the former and "no" to the latter. Is our stance that
answering "yes" to the former question is enough to motivate braking
change? Shouldn't a answer "no" to the latter question cause some
hesitation?

Maybe there are a lot of people who answer "yes" to both questions. I
would like to know! But does having return in the Monad class really
cause anyone anything other than existential pain?

Cheers,
Geoff

[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
[2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
[3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
[4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

_______________________________________________
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

Matthias Hörmann
I would say that the need to import Control.Applicative in virtually
every module manually
definitely caused some pain before AMP. I would also argue that a
non-negligible amount
of effort goes into teaching the warts, the reasons for the warts and
how to work around them.

> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP.

I am curious what exactly about AMP causes your research project to be
"stuck" on GHC 7.8
considering we have had multiple people mention how little effort it
took to update even large codebases.
I think it would be useful information to have to plan future changes
in a way that might avoid
your issues.

On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <[hidden email]> wrote:

> On 10/22/2015 02:40 AM, Edward Kmett wrote:
>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>>     <[hidden email] <mailto:[hidden email]>> 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?
>
> Thanks to you and Dan [1], I now have a greater understanding and
> appreciation for where the committee has been coming from. My new
> understanding is that the changes that were formalized in AMP, FTP, and
> MRP were the basis for the committee's creation. It also seems that
> there are more changes in the pipeline that have not yet been made into
> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
> "stability" is signaling change as far ahead as possible. The committee
> has put a lot of effort into this, which I appreciate! However, as each
> of these proposal has come down the pipeline, I never realized that they
> were part of a larger master plan.
>
> 1) What is the master plan, and where is it documented, even if this
> document is not up to the standard of a proposal? What is the final
> target, and when might we expect it to be reached? What is in the
> pipeline after MRP?
>
> Relatedly, guidance on how to write code now so that it will be
> compatible with future changes helps mitigate the stability issue.
>
> 2) How can I write code that makes use of the Prelude so that it will
> work with every new GHC release over the next 3 years? 5 years? For
> example, how can I write a Monad instance now, knowing the changes that
> are coming, so that the instance will work with every new GHC release
> for the next 3 years? 5 years? If the answer is "you can't," then when
> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> say I don't know the answer!
>
> Finally, if none of these changes broke Prelude backwards compatibility,
> far fewer people would be complaining :) Of course, we can't always make
> progress without breaking things, but a more deliberative process might
> offer an opportunity to make progress while still preserving backwards
> compatibility. Take AMP for example. There were at least two [3] [4]
> proposals for preserving backwards compatibility. Investigating them
> would have taken time and delayed AMP, yes, but why the rush?
>
> 3) Can we have a process that allows more deliberation over, and wider
> publicity for, changes that break backwards compatibility? The goal of
> such a process would not be to prevent change, but to allow more time to
> find possible solution to the issue of backwards compatibility.
>
> My proposal for a low-traffic mailing list where all proposals were
> announced was meant to provide wider publicity.
>
> Personally, I think these proposals do indeed fix a lot of warts in the
> language. As a researcher who uses actively uses Haskell every day,
> these warts have had approximately zero impact on me for the past
> (almost) decade, and I would be perfectly content if they were never
> fixed. The only pain I can recall enduring is having to occasionally
> write an orphan Applicative instance. I have been importing Prelude
> hiding mapM for years. I have been importing Control.Applicative for
> years. Neither has been painful. Dealing with AMP? I'm working on a
> collaborative research project that is stuck on 7.8 because of AMP. I
> agree, that seems silly, but whether or not it is silly, it is an impact
> I feel.
>
> One way to look at these proposals is to ask the question "Wouldn't the
> language be nicer if all these changes were made?" Another is to ask the
> question "Does the fact that these changes have not been made make your
> life as a Haskell programmer more difficult in any significant way?" I
> answer "yes" to the former and "no" to the latter. Is our stance that
> answering "yes" to the former question is enough to motivate braking
> change? Shouldn't a answer "no" to the latter question cause some
> hesitation?
>
> Maybe there are a lot of people who answer "yes" to both questions. I
> would like to know! But does having return in the Monad class really
> cause anyone anything other than existential pain?
>
> Cheers,
> Geoff
>
> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
>
> _______________________________________________
> 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

Geoffrey Mainland
On 10/22/2015 11:02 AM, Matthias Hörmann wrote:
> I would say that the need to import Control.Applicative in virtually
> every module manually
> definitely caused some pain before AMP.

In this particular case, there is a trade off between breaking code on
the one hand and having to write some import statements on the other. I
find writing some extra imports less painful than breaking (other
people's and my) code, but the other position is defensible as well. I
sense that I am in the minority, at least on the libraries list.

> I would also argue that a
> non-negligible amount
> of effort goes into teaching the warts, the reasons for the warts and
> how to work around them.

Which wart(s) in particular? All of them? Does having return (and (>>))
in Monad make teaching more difficult?

I teach Haskell beginners, and I found that AMP made explaining monads
slightly more difficult because it served as a source of confusion for
my students.

On the other hand, the warts provide a teachable moment once students
understand all this stuff :)

>> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP.
> I am curious what exactly about AMP causes your research project to be
> "stuck" on GHC 7.8
> considering we have had multiple people mention how little effort it
> took to update even large codebases.
> I think it would be useful information to have to plan future changes
> in a way that might avoid
> your issues.

I was hoping that mentioning this wouldn't distract from the three main
(numbered) questions I posed below. Alas.

If I were working alone, AMP wouldn't be a huge deal. I could fix the
code for 7.10 compatibility, but then unless everyone switches to 7.10,
changes to the codebase made by someone using 7.8, e.g., defining a new
Monad instance, could break things on 7.10 again. It's easier to stick
with 7.8. Any time spent dealing with compatibility issues is time not
spent writing actual code.

I outlined one possible path to avoid this kind of issue: spend more
time thinking about ways to maintain compatibility. We had proposals for
doing this with AMP.

Cheers,
Geoff

>
> On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <[hidden email]> wrote:
>> On 10/22/2015 02:40 AM, Edward Kmett wrote:
>>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>
>>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>>>     <[hidden email] <mailto:[hidden email]>> 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?
>> Thanks to you and Dan [1], I now have a greater understanding and
>> appreciation for where the committee has been coming from. My new
>> understanding is that the changes that were formalized in AMP, FTP, and
>> MRP were the basis for the committee's creation. It also seems that
>> there are more changes in the pipeline that have not yet been made into
>> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
>> "stability" is signaling change as far ahead as possible. The committee
>> has put a lot of effort into this, which I appreciate! However, as each
>> of these proposal has come down the pipeline, I never realized that they
>> were part of a larger master plan.
>>
>> 1) What is the master plan, and where is it documented, even if this
>> document is not up to the standard of a proposal? What is the final
>> target, and when might we expect it to be reached? What is in the
>> pipeline after MRP?
>>
>> Relatedly, guidance on how to write code now so that it will be
>> compatible with future changes helps mitigate the stability issue.
>>
>> 2) How can I write code that makes use of the Prelude so that it will
>> work with every new GHC release over the next 3 years? 5 years? For
>> example, how can I write a Monad instance now, knowing the changes that
>> are coming, so that the instance will work with every new GHC release
>> for the next 3 years? 5 years? If the answer is "you can't," then when
>> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
>> say I don't know the answer!
>>
>> Finally, if none of these changes broke Prelude backwards compatibility,
>> far fewer people would be complaining :) Of course, we can't always make
>> progress without breaking things, but a more deliberative process might
>> offer an opportunity to make progress while still preserving backwards
>> compatibility. Take AMP for example. There were at least two [3] [4]
>> proposals for preserving backwards compatibility. Investigating them
>> would have taken time and delayed AMP, yes, but why the rush?
>>
>> 3) Can we have a process that allows more deliberation over, and wider
>> publicity for, changes that break backwards compatibility? The goal of
>> such a process would not be to prevent change, but to allow more time to
>> find possible solution to the issue of backwards compatibility.
>>
>> My proposal for a low-traffic mailing list where all proposals were
>> announced was meant to provide wider publicity.
>>
>> Personally, I think these proposals do indeed fix a lot of warts in the
>> language. As a researcher who uses actively uses Haskell every day,
>> these warts have had approximately zero impact on me for the past
>> (almost) decade, and I would be perfectly content if they were never
>> fixed. The only pain I can recall enduring is having to occasionally
>> write an orphan Applicative instance. I have been importing Prelude
>> hiding mapM for years. I have been importing Control.Applicative for
>> years. Neither has been painful. Dealing with AMP? I'm working on a
>> collaborative research project that is stuck on 7.8 because of AMP. I
>> agree, that seems silly, but whether or not it is silly, it is an impact
>> I feel.
>>
>> One way to look at these proposals is to ask the question "Wouldn't the
>> language be nicer if all these changes were made?" Another is to ask the
>> question "Does the fact that these changes have not been made make your
>> life as a Haskell programmer more difficult in any significant way?" I
>> answer "yes" to the former and "no" to the latter. Is our stance that
>> answering "yes" to the former question is enough to motivate braking
>> change? Shouldn't a answer "no" to the latter question cause some
>> hesitation?
>>
>> Maybe there are a lot of people who answer "yes" to both questions. I
>> would like to know! But does having return in the Monad class really
>> cause anyone anything other than existential pain?
>>
>> Cheers,
>> Geoff
>>
>> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
>> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
>> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
>> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

_______________________________________________
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

Mario Blažević
In reply to this post by Geoffrey Mainland
On 15-10-22 09:29 AM, Geoffrey Mainland wrote:
> ...
>
> 1) What is the master plan, and where is it documented, even if this
> document is not up to the standard of a proposal? What is the final
> target, and when might we expect it to be reached? What is in the
> pipeline after MRP?
>
> Relatedly, guidance on how to write code now so that it will be
> compatible with future changes helps mitigate the stability issue.

        I have been fully in favour of all the proposals implemented so far,
and I think that having an explicit master plan would be a great idea.
It would address some of the process-related objections that have been
raised, and it would provide a fixed long-term target that would be much
easier to make the whole community aware of and contribute to.

        For that purpose, the master plan should be advertised directly on the
front page of haskell.org. Once we have it settled and agreed, the
purpose of the base-library commitee would essentially become to figure
out the details like the timeline and code migration path. One thing
they wouldn't need to worry about is whether anybody disagrees with
their goals.


> 2) How can I write code that makes use of the Prelude so that it will
> work with every new GHC release over the next 3 years? 5 years? For
> example, how can I write a Monad instance now, knowing the changes that
> are coming, so that the instance will work with every new GHC release
> for the next 3 years? 5 years? If the answer is "you can't," then when
> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
> say I don't know the answer!

        From the discussions so far it appears that the answer for 3 years (or
at least the next 3 GHC releases) would be to write the code that works
with the current GHC and base, but this policy has not been codified
anywhere yet. Knowing the upcoming changes doesn't help with making your
code any more robust, and I think that's a shame. We could have a
two-pronged policy:

- code that works and compiles with the latest GHC with no *warnings*
will continue to work and compile with no *errors* with the following 2
releases, and
- code that also follows the forward-compatibility recommendations
current for that version of GHC will continue to work and compile with
no *errors* with the following 4 releases.

        The forward-compatibility recommendations would become a part of the
online GHC documentation so nobody complains they didn't know about
them. Personally, I'd prefer if the recommendations were built into the
compiler itself as a new class of warnings, but then (a) some people
would insist on turning them on together with -Werror and then complain
when their builds break and (b) this would increase the pressure on GHC
implementors.


> Finally, if none of these changes broke Prelude backwards compatibility,
> far fewer people would be complaining :) Of course, we can't always make
> progress without breaking things, but a more deliberative process might
> offer an opportunity to make progress while still preserving backwards
> compatibility. Take AMP for example. There were at least two [3] [4]
> proposals for preserving backwards compatibility. Investigating them
> would have taken time and delayed AMP, yes, but why the rush?

        Because they have been investigated for years with no effect.


> 3) Can we have a process that allows more deliberation over, and wider
> publicity for, changes that break backwards compatibility? The goal of
> such a process would not be to prevent change, but to allow more time to
> find possible solution to the issue of backwards compatibility.

        I doubt we can, but this question has already been answered by others.

_______________________________________________
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

Edward Kmett-2
In reply to this post by Geoffrey Mainland

On Thu, Oct 22, 2015 at 9:29 AM, Geoffrey Mainland <[hidden email]> wrote:
Thanks to you and Dan [1], I now have a greater understanding and
appreciation for where the committee has been coming from. My new
understanding is that the changes that were formalized in AMP, FTP, and
MRP were the basis for the committee's creation. It also seems that
there are more changes in the pipeline that have not yet been made into
proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
"stability" is signaling change as far ahead as possible. The committee
has put a lot of effort into this, which I appreciate! However, as each
of these proposal has come down the pipeline, I never realized that they
were part of a larger master plan.

The "master plan" where (>>) is concerned is that it'd be nice to get Traversable down to a minimal state and to eliminate unnecessary distinctions in the Prelude between things like mapM and traverse. Right now they have different type constraints, but this is entirely a historical artifact. But it causes problems, we have a situation where folks have commonly optimized (>>) but left (*>) unfixed. This yields different performance for mapM_ and traverse_. A consequence of the AMP is that the neither one of those could be defined in terms of the other (*>) has a default definition in terms of (<*>). (>>) has a default definition in terms of (>>=). With two places where optimizations can happen and two different definitions for operations that are logically required to be the same thing we can and do see rather radically different performance between these two things.

This proposal is something that was put out as a sort of addendum to the Monad of No Return proposal for discussion, but unlike MRP has no particular impact on a sacred cow like return. We have yet to put together a timeline that incorporates the (>>) changes from MRP.

1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be
compatible with future changes helps mitigate the stability issue.

The current plans more or less stop with finishing the MonadFail proposal, getting Semigroup in as a superclass of Monoid, and incorporating some additional members into Floating. The working document for the timeline going forward is available here:


2) How can I write code that makes use of the Prelude so that it will
work with every new GHC release over the next 3 years? 5 years? For
example, how can I write a Monad instance now, knowing the changes that
are coming, so that the instance will work with every new GHC release
for the next 3 years? 5 years? If the answer is "you can't," then when
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
say I don't know the answer!

We have a backwards facing "3 release policy" that says it should always be possible to write code that works backwards for 3 releases. This means that changes like moving fail out of Monad will take 5 years. However, maintaining both that and a _forward facing_ 3 release policy would mean that any change that introduced a superclass would take something like 9 years of intermediate states that make no sense to complete. 9 years to move one method.

Now looking forward. You can write code today with 7.10 that will work without warnings until 8.2. That happens to be 3 releases. In 8.4 you'll start to get warnings about Semigroup and MonadFail changes, but looking at it as 3 releases going forward in 8.0 you can just write the instances and your code would be warning free forward for 3 releases. In 8.6 those changes go into effect, but you will have been able to make the code changes that you need to accomodate 8.6 since 8.0.

The current roadmap happens to give you a 3 year sliding window.

Finally, if none of these changes broke Prelude backwards compatibility,
far fewer people would be complaining :)

If none of our changes were ever able to break Prelude backwards compatibility the same people who have been complaining about the utter lack of progress for the previous 17 years and that nearly exploded the community 2 years ago would be complaining, and based on polling and discusssions that is actually a much larger group. The AMP passed nearly unanimously.
 
Of course, we can't always make
progress without breaking things, but a more deliberative process might
offer an opportunity to make progress while still preserving backwards
compatibility. Take AMP for example. There were at least two [3] [4]
proposals for preserving backwards compatibility. Investigating them
would have taken time and delayed AMP, yes, but why the rush?

We've been talking about various superclass defaulting proposals for the better part of a decade and no progress has been made. The rush was that we'd been letting them block every previous discussion, and that the concrete plan with an actual implementation that was on hand was a very popular proposal even without that mitigation strategy.

3) Can we have a process that allows more deliberation over, and wider
publicity for, changes that break backwards compatibility? The goal of
such a process would not be to prevent change, but to allow more time to
find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were
announced was meant to provide wider publicity.

I don't think anybody has an objection to wider visibility of proposals that affect things mentioned in the Haskell Report.
 
Personally, I think these proposals do indeed fix a lot of warts in the
language. As a researcher who uses actively uses Haskell every day,
these warts have had approximately zero impact on me for the past
(almost) decade, and I would be perfectly content if they were never
fixed. The only pain I can recall enduring is having to occasionally
write an orphan Applicative instance. I have been importing Prelude
hiding mapM for years. I have been importing Control.Applicative for
years. Neither has been painful.

And yet the vast preponderance of public opinion lies in the other camp. The "change nothing" policy had an iron grip on the state of affairs for 17 years and there were serious cracks starting to form from the appearance that nothing could ever be fixed if the Prelude was affected in any way.

The only thing that broke with that was when Ian Lynagh unilaterally removed Eq and Show as superclasses of Num. That was more or less the first glimmer that the world wouldn't end if deliberated changes were made to the Prelude.

Dealing with AMP? I'm working on a
collaborative research project that is stuck on 7.8 because of AMP. I
agree, that seems silly, but whether or not it is silly, it is an impact
I feel.

What changes did you face beyond writing

instance Functor Foo where
  fmap = liftM

instance Applicative Foo where
  pure = return
  (<*>) = ap

that is AMP related?

Maybe there are a lot of people who answer "yes" to both questions. I
would like to know! But does having return in the Monad class really
cause anyone anything other than existential pain?

The MRP is by far the most marginal proposal on the table. This is why it remains just a proposal and not part of the roadmap. That said, moving return to a top level definition will mean that more code that is compiled will be able to infer an Applicative constraint.

The other proposals that are on the roadmap on the other hand defend a lot better.

The (>>) fragment of MRP fixes rampant performance regressions, however. We went to generalize the implementation of mapM_ to use (*>) internally and found performance regressions within base itself due to instances that are optimized inconsistently. This informed the design here. More code will infer with weaker Applicative constraints, Traversable can eventually be simplified, and folks like Simon Marlow who have folks internally at Facebook use mapM will just have their code "work" in Haxl. I can answer "yes" to both of your questions here.

The continued existence of fail in Monad on the other hand has caused a great deal of pain in instances for things like `Either a` for years. To supply `fail`, we used to incur a needless Error a constraint. We can be more precise and remove a potential source of partiality from a lot of code. I can answer "yes" to both of your questions here.

The lack of Semigroup as a superclass of Monoid has meant that the Monoid instance for Maybe adds a unit to something that already has a unit. It means that First and Last, etc. all useless tack an extra case that everyone has to handle in. It has dozens of knock-on consequences. Much code that currently only needs a semigroup falls back on a monoid because of the lack of a proper class relationship or gets duplicated. I can answer "yes" to both of your questions here.

The numerics changes to Floating mean that Haskell numerics just have awful precision. Adding expm1, etc. to Floating means that people will be able to write decent numerical code without having to choose between generality (using exp from Floating that works everywhere) and accuracy. I can answer "yes" to both of your questions here.

-Edward

_______________________________________________
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

Edward Kmett-2
In reply to this post by Geoffrey Mainland
On Thu, Oct 22, 2015 at 11:36 AM, Geoffrey Mainland <[hidden email]> wrote:
On 10/22/2015 11:02 AM, Matthias Hörmann wrote:
> I would say that the need to import Control.Applicative in virtually
> every module manually
> definitely caused some pain before AMP.

In this particular case, there is a trade off between breaking code on
the one hand and having to write some import statements on the other. I
find writing some extra imports less painful than breaking (other
people's and my) code, but the other position is defensible as well. I
sense that I am in the minority, at least on the libraries list.

> I would also argue that a
> non-negligible amount
> of effort goes into teaching the warts, the reasons for the warts and
> how to work around them.

Which wart(s) in particular? All of them? Does having return (and (>>))
in Monad make teaching more difficult?

Having (>>) means that we have hundreds of monads out there where (>>) has been optimized, but (*>) has not.  

If I were working alone, AMP wouldn't be a huge deal. I could fix the
code for 7.10 compatibility, but then unless everyone switches to 7.10,
changes to the codebase made by someone using 7.8, e.g., defining a new
Monad instance, could break things on 7.10 again. It's easier to stick
with 7.8. Any time spent dealing with compatibility issues is time not
spent writing actual code.

In the open source world many of us just fire off our code to travis-ci and get it to build with a dozen different compiler versions. I maintain a lot of code that supports things back to 7.0 and forward to HEAD this way.
 
I outlined one possible path to avoid this kind of issue: spend more
time thinking about ways to maintain compatibility. We had proposals for
doing this with AMP.

And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own.

-Edward
 
Cheers,
Geoff

>
> On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <[hidden email]> wrote:
>> On 10/22/2015 02:40 AM, Edward Kmett wrote:
>>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>
>>>     On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland
>>>     <[hidden email] <mailto:[hidden email]>> 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?
>> Thanks to you and Dan [1], I now have a greater understanding and
>> appreciation for where the committee has been coming from. My new
>> understanding is that the changes that were formalized in AMP, FTP, and
>> MRP were the basis for the committee's creation. It also seems that
>> there are more changes in the pipeline that have not yet been made into
>> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of
>> "stability" is signaling change as far ahead as possible. The committee
>> has put a lot of effort into this, which I appreciate! However, as each
>> of these proposal has come down the pipeline, I never realized that they
>> were part of a larger master plan.
>>
>> 1) What is the master plan, and where is it documented, even if this
>> document is not up to the standard of a proposal? What is the final
>> target, and when might we expect it to be reached? What is in the
>> pipeline after MRP?
>>
>> Relatedly, guidance on how to write code now so that it will be
>> compatible with future changes helps mitigate the stability issue.
>>
>> 2) How can I write code that makes use of the Prelude so that it will
>> work with every new GHC release over the next 3 years? 5 years? For
>> example, how can I write a Monad instance now, knowing the changes that
>> are coming, so that the instance will work with every new GHC release
>> for the next 3 years? 5 years? If the answer is "you can't," then when
>> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
>> say I don't know the answer!
>>
>> Finally, if none of these changes broke Prelude backwards compatibility,
>> far fewer people would be complaining :) Of course, we can't always make
>> progress without breaking things, but a more deliberative process might
>> offer an opportunity to make progress while still preserving backwards
>> compatibility. Take AMP for example. There were at least two [3] [4]
>> proposals for preserving backwards compatibility. Investigating them
>> would have taken time and delayed AMP, yes, but why the rush?
>>
>> 3) Can we have a process that allows more deliberation over, and wider
>> publicity for, changes that break backwards compatibility? The goal of
>> such a process would not be to prevent change, but to allow more time to
>> find possible solution to the issue of backwards compatibility.
>>
>> My proposal for a low-traffic mailing list where all proposals were
>> announced was meant to provide wider publicity.
>>
>> Personally, I think these proposals do indeed fix a lot of warts in the
>> language. As a researcher who uses actively uses Haskell every day,
>> these warts have had approximately zero impact on me for the past
>> (almost) decade, and I would be perfectly content if they were never
>> fixed. The only pain I can recall enduring is having to occasionally
>> write an orphan Applicative instance. I have been importing Prelude
>> hiding mapM for years. I have been importing Control.Applicative for
>> years. Neither has been painful. Dealing with AMP? I'm working on a
>> collaborative research project that is stuck on 7.8 because of AMP. I
>> agree, that seems silly, but whether or not it is silly, it is an impact
>> I feel.
>>
>> One way to look at these proposals is to ask the question "Wouldn't the
>> language be nicer if all these changes were made?" Another is to ask the
>> question "Does the fact that these changes have not been made make your
>> life as a Haskell programmer more difficult in any significant way?" I
>> answer "yes" to the former and "no" to the latter. Is our stance that
>> answering "yes" to the former question is enough to motivate braking
>> change? Shouldn't a answer "no" to the latter question cause some
>> hesitation?
>>
>> Maybe there are a lot of people who answer "yes" to both questions. I
>> would like to know! But does having return in the Monad class really
>> cause anyone anything other than existential pain?
>>
>> Cheers,
>> Geoff
>>
>> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html
>> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html
>> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates
>> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

_______________________________________________


_______________________________________________
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

>     I outlined one possible path to avoid this kind of issue: spend more
>     time thinking about ways to maintain compatibility. We had
>     proposals for
>     doing this with AMP.
>
>
> And on the other hand we also had a concrete proposal that didn't
> require language changes that was ridiculously popular. People had
> been talking about Applicative as a superclass of Monad for a decade
> before we finally acted upon the AMP. People had been talking about
> superclass defaulting for a decade. When do you cut off discussion and
> ship the proposal that has overwhelming support? If there is no
> process that enables this you can stall the process indefinitely by
> raising objections of this form. Such a situation is not without costs
> all its own.
>

I agree. It was certainly within the power of the committee to start a
clock and say something like "if we don't have a patch to GHC that
provides backwards compatibility for AMP within 1 year, we will push out
AMP as-is." Had I understand the implications of AMP at the time, or
even been aware that AMP was happening (I was actually actively working
on the GHC code base during that period), that certainly would have been
motivation for me to do something about it! *That* would be how one
could cut off discussion and ship a proposal.

I am not against changing the Prelude! But it sure would be nice if
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
Haskell 2010 Prelude, both of which could be used with external packages
that themselves used the more modern Prelude. Maybe that's impossible.
Setting a firm deadline to finding a solution to the compatibility issue
would have been a way to compromise. Ideally, changing the Prelude
wouldn't require breaking code written to use an older version of the
Prelude. Yes, attaining that goal would require more work.

Evolving the Prelude and maintaining compatibility are not necessarily
mutually exclusive options.

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 am not against changing the Prelude! But it sure would be nice if
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
Haskell 2010 Prelude, both of which could be used with external packages
that themselves used the more modern Prelude.

This sounds like quite a herculean task. Changes in base type-classes would wreak havoc between preludes from differing timelines.

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