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

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

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell.

Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it.

Regards,
Malcolm

> On 5 Oct 2015, at 10:05, Malcolm Wallace wrote:
>
>> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits.
>>
>> Regards,
>> Malcolm
>>
>> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote:
>>
>>> Hi all,
>>>
>>> I have discussed the monad of no return proposal with
>>> my colleague Graham Hutton: a long-standing member of
>>> the Haskell community, well-known researcher, some 20
>>> years of experience of teaching Haskell to
>>> undergraduate students, and author of one of the most
>>> successful introductory Haskell textbooks there are.
>>>
>>> The upshot of this e-mail is a strong collective -2
>>> from us both on particular proposal, and a general call
>>> for much more caution when it comes to breaking changes
>>> that are not critically important.
>>>
>>> First, on a general note, there has recently been a
>>> flurry of breaking changes to the (de facto) Haskell
>>> standards. In many cases for very good reasons, but
>>> sometimes it seems more in a quest for perfection
>>> without due consideration for the consequences. It used
>>> to be the case that breaking changes were very rare
>>> indeed. And for good reason.
>>>
>>> Right now, the main "measure of breakage" in the
>>> on-line discussions seems to be how many packages that
>>> break in Hackage. Which of course makes sense: the
>>> Hackage repository is very important and such a measure
>>> is objective, as far as it goes.
>>>
>>> But we should not forget that breakage can go far
>>> beyond Hackage. For starters, there is *lots* of code
>>> that is not in Hackage, yet critically important to its
>>> users, however many or few they are. There are more
>>> than hundreds of thousands of copies of books out there
>>> where that may break in that examples may no longer
>>> work. And they cannot be changed. There are countless
>>> research papers that may break in the same way. Every
>>> single institution that use Haskell in their teaching
>>> may have to update their teaching materials (slides,
>>> code, lab instructions) for every module that teaches
>>> or uses Haskell. And last but not the least, what
>>> countless of programmers and students have learned
>>> about Haskell over decades, most of whom are *not*
>>> power users who can take these changes in their stride,
>>> may also break.
>>>
>>> Now, of course a language has to evolve, and sometimes
>>> breaking backwards compatibility is more or less
>>> essential for the long-term benefit of the language.
>>> But we should not let perfection be the enemy of the
>>> good.
>>>
>>> As to this particular proposal, the monad of no return,
>>> it does not seem essential to us, but mostly motivated
>>> by a quest for "perfection" as defined by a very
>>> knowledgeable but in relative terms small group of
>>> people.
>>>
>>> One argument put forward was that applicative code that
>>> uses "return" instead of "pure" should get a less
>>> constrained type. But such code is relatively new. The
>>> methods of the Monad class have been return and bind
>>> for some 25 years. So indeed, as Henning Thielemann
>>> wrote: why should not the newer code be adapted and use
>>> "pure" instead? In fact, the use of "pure" in such code
>>> could serve as a quite useful cue that the code is
>>> applicative rather than monadic, especially where
>>> applicative do is employed.
>>>
>>> Another reason put forward is support for the
>>> applicative do syntax. But that is, in standard terms,
>>> only a future possibility at this point. Further, the
>>> syntax is arguably rather dubious anyway as it, in
>>> particular to someone with an imperative background,
>>> suggests a sequential reading which is exactly what
>>> applicative is not and why it is useful. So from that
>>> perspective, using the applicative operators directly,
>>> without any syntactic sugar, actually amounts to a much
>>> more transparent and honest syntax, even if a bit more
>>> verbose in some cases.
>>>
>>> The bottom line is that it is premature to put forward
>>> support for the applicative do syntax as a rationale
>>> for a non-essential breaking change.
>>>
>>> Best regards,
>>>
>>> Henrik Nilsson and Graham Hutton
>>>
>>> --
>>> Henrik Nilsson
>>> School of Computer Science
>>> The University of Nottingham
>>> [hidden email]>>
>

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

Hi,

As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change:

1. Orthogonal type classes are easier to explain.

2. Gradual improvements helps us to generalize further, and this in turn makes education easier.

3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited.

That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own.

So:

+1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library.

That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability?

PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral".

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be

I did this because it means curious students don't need to receive an
explanation of the historical accidents of Haskell had I modelled it in
accordance with Haskell pre-AMP. Doing so has caused confusion (I tried
it, many years ago).

Since AMP implementation, I have changed the hierarchy to be the same as
Haskell proper, since the benefit has become worth doing.

I am in favour of breaking changes as hard as you can, if it achieves a
progressive benefit, even a small one, which this does. It also achieves
an incidental benefit in the context of teaching.

As it stands for industry use, I remove Prelude and model all this
properly anyway. It is a significant effort, but way worth it e.g. do
not require return to use do-notation. The penalty for having to do this
is often under-estimated. "Breaking changes" is over-stated.

Patience. I am waiting.

On 05/10/15 19:30, Malcolm Wallace wrote:

> On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell.
>
> Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it.
>
> Regards,
> Malcolm
>
>
>> On 5 Oct 2015, at 10:05, Malcolm Wallace wrote:
>>
>>> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits.
>>>
>>> Regards,
>>> Malcolm
>>>
>>> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have discussed the monad of no return proposal with
>>>> my colleague Graham Hutton: a long-standing member of
>>>> the Haskell community, well-known researcher, some 20
>>>> years of experience of teaching Haskell to
>>>> undergraduate students, and author of one of the most
>>>> successful introductory Haskell textbooks there are.
>>>>
>>>> The upshot of this e-mail is a strong collective -2
>>>> from us both on particular proposal, and a general call
>>>> for much more caution when it comes to breaking changes
>>>> that are not critically important.
>>>>
>>>> First, on a general note, there has recently been a
>>>> flurry of breaking changes to the (de facto) Haskell
>>>> standards. In many cases for very good reasons, but
>>>> sometimes it seems more in a quest for perfection
>>>> without due consideration for the consequences. It used
>>>> to be the case that breaking changes were very rare
>>>> indeed. And for good reason.
>>>>
>>>> Right now, the main "measure of breakage" in the
>>>> on-line discussions seems to be how many packages that
>>>> break in Hackage. Which of course makes sense: the
>>>> Hackage repository is very important and such a measure
>>>> is objective, as far as it goes.
>>>>
>>>> But we should not forget that breakage can go far
>>>> beyond Hackage. For starters, there is *lots* of code
>>>> that is not in Hackage, yet critically important to its
>>>> users, however many or few they are. There are more
>>>> than hundreds of thousands of copies of books out there
>>>> where that may break in that examples may no longer
>>>> work. And they cannot be changed. There are countless
>>>> research papers that may break in the same way. Every
>>>> single institution that use Haskell in their teaching
>>>> may have to update their teaching materials (slides,
>>>> code, lab instructions) for every module that teaches
>>>> or uses Haskell. And last but not the least, what
>>>> countless of programmers and students have learned
>>>> about Haskell over decades, most of whom are *not*
>>>> power users who can take these changes in their stride,
>>>> may also break.
>>>>
>>>> Now, of course a language has to evolve, and sometimes
>>>> breaking backwards compatibility is more or less
>>>> essential for the long-term benefit of the language.
>>>> But we should not let perfection be the enemy of the
>>>> good.
>>>>
>>>> As to this particular proposal, the monad of no return,
>>>> it does not seem essential to us, but mostly motivated
>>>> by a quest for "perfection" as defined by a very
>>>> knowledgeable but in relative terms small group of
>>>> people.
>>>>
>>>> One argument put forward was that applicative code that
>>>> uses "return" instead of "pure" should get a less
>>>> constrained type. But such code is relatively new. The
>>>> methods of the Monad class have been return and bind
>>>> for some 25 years. So indeed, as Henning Thielemann
>>>> wrote: why should not the newer code be adapted and use
>>>> "pure" instead? In fact, the use of "pure" in such code
>>>> could serve as a quite useful cue that the code is
>>>> applicative rather than monadic, especially where
>>>> applicative do is employed.
>>>>
>>>> Another reason put forward is support for the
>>>> applicative do syntax. But that is, in standard terms,
>>>> only a future possibility at this point. Further, the
>>>> syntax is arguably rather dubious anyway as it, in
>>>> particular to someone with an imperative background,
>>>> suggests a sequential reading which is exactly what
>>>> applicative is not and why it is useful. So from that
>>>> perspective, using the applicative operators directly,
>>>> without any syntactic sugar, actually amounts to a much
>>>> more transparent and honest syntax, even if a bit more
>>>> verbose in some cases.
>>>>
>>>> The bottom line is that it is premature to put forward
>>>> support for the applicative do syntax as a rationale
>>>> for a non-essential breaking change.
>>>>
>>>> Best regards,
>>>>
>>>> Henrik Nilsson and Graham Hutton
>>>>
>>>> --
>>>> Henrik Nilsson
>>>> School of Computer Science
>>>> The University of Nottingham
>>>> [hidden email]>>>
>>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime>

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

It’s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken.

Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future.

If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There’s an old fashioned maxim that sums this up in a pithy way: “if it ain’t broke, don’t fix it”.

As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change:

1. Orthogonal type classes are easier to explain.

2. Gradual improvements helps us to generalize further, and this in turn makes education easier.

3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited.

That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own.

So:

+1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library.

That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability?

PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral".

On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/10/15 15:16, Brandon Allbery wrote:
> On Mon, Oct 5, 2015 at 8:16 AM, Alexander Berntsen wrote:
>> But... it *is* broken.
> Somehow, we managed to use Monad before this. That does not sound
> "broken".
Just because something is broken does not mean that it is not possible
to use it. We use broken things and are subject to broken systems all
day every day.

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

[...] It’s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. [...]

I wouldn't necessarily call the process "broken", but it's a bit annoying: Because of the constant flux of minor changes in the language and the libraries, I've reached the stage where I'm totally unable to tell if my code will work for the whole GHC 7.x series. The only way I see is doing heavy testing on Travis CI and littering the code with #ifdefs after compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No clue how to do that...) This is less than satisfactory IMHO, and I would really prefer some other mode for introducing such changes: Perhaps these should be bundled and released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way some stuff which belongs together (AMP, FTP, kicking out return, etc.) comes in slightly larger, but more sensible chunks.

Don't get me wrong: Most of the proposed changes in itself are OK and should be done, it's only the way they are introduced should be improved...

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

> Hello all. I write this to be a little provocative, but …
>
> It’s really interesting to have this discussion, which pulls in all sorts of well-made
> points about orthogonality, teaching, the evolution of the language and so on, but it
> simply goes to show that the process of evolving Haskell is profoundly broken.
>
> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes
> that would have a profound impact on systems that are commercially and potentially safety
> critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility
> of the Haskell community to its users and, indirectly, to its future.

Hi Simon. I do in fact think this is provocative :-P

I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.

I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.

Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?

—Gershom

P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.
_______________________________________________
Haskell-prime mailing list
[hidden email]http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

> 2015-10-05 11:59 GMT+02:00 Simon Thompson <[hidden email]>:
>
>> [...] It’s really interesting to have this discussion, which pulls in all
>> sorts of well-made points about orthogonality, teaching, the evolution of
>> the language and so on, but it simply goes to show that the process of
>> evolving Haskell is profoundly broken. [...]
>>
>
> I wouldn't necessarily call the process "broken", but it's a bit
> annoying: Because of the constant flux of minor changes in the
> language and the libraries, I've reached the stage where I'm totally
> unable to tell if my code will work for the whole GHC 7.x series. The
> only way I see is doing heavy testing on Travis CI and littering the
> code with #ifdefs after compilation failures. (BTW: Fun exercise: Try
> using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for
> keeping the #ifdefs centralized. No clue how to do that...) This is
> less than satisfactory IMHO, and I would really prefer some other mode
> for introducing such changes: Perhaps these should be bundled and
> released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way
> some stuff which belongs together (AMP, FTP, kicking out return, etc.)
> comes in slightly larger, but more sensible chunks.
>
> Don't get me wrong: Most of the proposed changes in itself are OK and
> should be done, it's only the way they are introduced should be
> improved...

I think that part of the reason we have seen these changes occur in a
"constant flux" rather than in bigger coordinated chunks is that faith
in the Haskell Report process was (understandably) abandoned. And
without the Haskell Report as some kind of "clock generator" with which
to align/bundle related changes into logical units, changes occur
whenever they're proposed and agreed upon (which may take several
attempts as we've seen with the AMP and others).

I hope that the current attempt to revive the Haskell Prime process will
give us a chance to clean up the unfinished intermediate `base-4.8`
situation we're left with now after AMP, FTP et al, as the next Haskell
Report revision provides us with a milestone to work towards.

That being said, there's also the desire to have changes field-tested by
a wide audience on a wide range before integrating them into a Haskell
Report. Also I'm not sure if there would be less complaints if
AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on
all at once in e.g. `base-5.0`, breaking almost *every* single package
out there at once.

For language changes we have a great way to field-test new extensions
before integrating them into the Report via `{-# LANGUAGE #-}` pragmas
in a nicely modular and composable way (i.e. a package enabling a
certain pragma doesn't require other packages to use it as well) which
have proven to be quite popular.

However, for the library side we lack a comparable mechanism at this
point. The closest we have, for instance, to support an isolated
Haskell2010 legacy environment is to use RebindableSyntax which IMO
isn't good enough in its current form[1]. And then there's the question
whether we want a Haskell2010 legacy environment that's isolated or
rather shares the types & typeclasses w/ `base`. If we require sharing
types and classes, then we may need some facility to implicitly
instanciate new superclasses (e.g. implicitly define Functor and
Applicative if only a Monad instance is defined). If we don't want to
share types & classes, we run into the problem that we can't easily mix
packages which depend on different revisions of the standard-library
(e.g. one using `base-4.8` and others which depend on a legacy
`haskell2010` base-API). One way to solve this could be to mutually
exclude depending on both , `base-4.8` and `haskell2010`, in the same
install-plan (assuming `haskell2010` doesn't depend itself on
`base-4.8`)

In any case, I think we will have to think hard how to address
language/library change management in the future, especially if the
Haskell code-base continues to grow. Even just migrating the code base
between Haskell Report revisions is a problem. An extreme example
is the Python 2->3 transition which the Python ecosystem is still
suffering from today (afaik). Ideas welcome!

[1]: IMO, we need something to be used at the definition site providing
desugaring rules, rather than requiring the use-site to enable a
generalised desugaring mechanism; I've been told that Agda has an
interesting solution to this in its base libraries via
{-# LANGUAGE BUILTIN ... #-} pragmas.

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

I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed – and to general approval, no less – on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing.

I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously.

Thanks,
Bryan.

> On Oct 5, 2015, at 7:32 AM, Gershom B <[hidden email]> wrote:
>
>> On October 5, 2015 at 6:00:00 AM, Simon Thompson ([hidden email]) wrote:
>> Hello all. I write this to be a little provocative, but …
>>
>> It’s really interesting to have this discussion, which pulls in all sorts of well-made
>> points about orthogonality, teaching, the evolution of the language and so on, but it
>> simply goes to show that the process of evolving Haskell is profoundly broken.
>>
>> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes
>> that would have a profound impact on systems that are commercially and potentially safety
>> critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility
>> of the Haskell community to its users and, indirectly, to its future.
>
> Hi Simon. I do in fact think this is provocative :-P
>
> I want to object here to your characterization of what has been going on as “simply throwing in changes”. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period.
>
> I also want to object to the idea that these changes would have “a profound impact on systems”. As it stands, and I think this is an important criteria in any change, when “phase 2” goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior.
>
> Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind?
>
> —Gershom
>
> P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns.
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

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

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:
> I would like to suggest that the bar for breaking all existing libraries, books, papers,
> and lecture notes should be very high; and that the benefit associated with such a breaking
> change should be correspondingly huge.
>

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

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

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan ([hidden email]) wrote:[...] As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. [...]

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends...

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

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to cause problems and work for me than it is doing to improve the common infrastructure.

On the libraries I maintain and have a copy of on my computer right now: 329

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

On 5 October 2015 at 20:58, Sven Panne <[hidden email]> wrote:
> 2015-10-05 17:09 GMT+02:00 Gershom B <[hidden email]>:
>>>> [...] As for libraries, it has been pointed out, I believe, that without
>> CPP one can write instances compatible with AMP, and also with AMP + MRP.
>> One can also write code, sans CPP, compatible with pre- and post- AMP. [...]
>
> Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is
> now part of the Prelude, you can't simply import some compatibility module,
> because GHC might tell you (rightfully) that that import is redundant,
> because (<$>) is already visible through the Prelude. So you'll have to use
> CPP to avoid that import on base >= 4.8, be it from it Data.Functor,
> Control.Applicative or some compat-* module. And you'll have to use CPP in
> each and every module using <$> then, unless I miss something obvious.
> AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a
bit fragile but that page says it works and it avoids CPP.

No it doesn't, if you also don't want closed import lists (which you should).

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

> If you take e.g. (<$>) which is now part of the Prelude, you can't
> simply import some compatibility module, because GHC might tell you
> (rightfully) that that import is redundant, because (<$>) is already
> visible through the Prelude.

Yes, the proper solution is slightly more complicated than just
importing Prelude.Compat [1]. You also have to specify "import
Prelude ()" -- or compile with NoImplicitPrelude, if you prefer
that kind of thing.

On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <[hidden email]> wrote:
>> Also I'm not sure if there would be less complaints if
>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>> at once.
>
> I doubt the number of complaints-per-change would be fewer, but I'm strongly
> in favor of moving away from what feels like a treadmill that doesn't value
> the time of developers and that doesn't account for the
> more-than-sum-of-parts cost of the "constant flux".

Broadly speaking, I'm a "fix it now rather than later" sort of person
in Haskell because I've seen how long things can linger before finally
getting fixed (even when everyone agrees on what the fix should be and
agrees that it should be done). However, as I mentioned in the
originating thread, I think that —at this point— when it comes to
AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
work out a comprehensive solution (as soon as possible), and then
enact all the changes at once when switching to
Haskell201X/base-5.0/whatevs. I understand the motivations for wanting
things to be field-tested before making it into the report, but I
don't think having a series of rapid incremental changes is the
correct approach here. Because we're dealing with the Prelude and the
core classes, the amount of breakage (and CPP used to paper over it)
here is much higher than our usual treadmill of changes; so we should
take that into account when planning how to roll the changes out.

> On the libraries I maintain and have a copy of on my computer right now: 329

Although this was already pointed out to you in a response to a Tweet of
yours, I'd like to expand on this here to clarify:

You say that you stick to the 3-major-ghc-release support-window
convention for your libraries. This is good, because then you don't need
any CPP at all! Here's why:

So when GHC 8.2 is released, your support-window requires you to support
GHC 7.10 and GHC 8.0 in addition to GHC 8.2.

At this point you'll be happy that you can start dropping those #ifdefs
you added for GHC 7.10 in your code in order to adapt to FTP & AMP.

And when you do *that*, you can also drop all your `return = pure`
methods overrides. (Because we prepared for MRP already in GHC 7.10 by
introducing the default implementation for `return`!)

This way, you don't need to introduce any CPP whatsoever due to MRP!

Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC
8.2 was just the *earliest theoretical* possible GHC in which this
*could* have happened. Realistically, this would happen at a much later
point, say GHC 8.6 or even later! Therefore, the scheme above would
actually work for 5-year time-windows! And there's even an idea on the
table to have a lawful `return = pure` method override be tolerated by
GHC even when `return` has already moved out of `Monad`!

PS: I'm a bit disappointed you seem to dismiss this proposal right away
categorically without giving us a chance to address your
concerns. The proposal is not a rigid all-or-nothing thing that
can't be tweaked and revised. That's why we're having these
proposal-discussions in the first place (rather than doing blind
+1/-1 polls), so we can hear everyone out and try to maximise the
agreement (even if we will never reach 100% consensus on any
proposal).

Re: Language Change Management

> On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <[hidden email]> wrote:
>>> Also I'm not sure if there would be less complaints if
>>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>>> at once.
>>
>> I doubt the number of complaints-per-change would be fewer, but I'm strongly
>> in favor of moving away from what feels like a treadmill that doesn't value
>> the time of developers and that doesn't account for the
>> more-than-sum-of-parts cost of the "constant flux".
>
> Broadly speaking, I'm a "fix it now rather than later" sort of person
> in Haskell because I've seen how long things can linger before finally
> getting fixed (even when everyone agrees on what the fix should be and
> agrees that it should be done). However, as I mentioned in the
> originating thread, I think that —at this point— when it comes to
> AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
> work out a comprehensive solution (as soon as possible), and then
> enact all the changes at once when switching to
> Haskell201X/base-5.0/whatevs.

In general: Yes, when everybody more or less agrees what the Right Thing
then this is probably the way to go. (But it still carries the risk of
e.g. C++ "template exports" which seemed a good idea a the time, but was
unimplementable.)

In this specific case: Isn't the proposal under discussion here more or
less the end game for the change to Applicative/Monad? (I mean, I don't
think anyone's seriously suggesting *removing* "return" completely any
time soon.)

If so, then I think the only thing punting this specific proposal to the
new Haskell' committe will achieve is to postpone the stream of
complaints :).

Plus, we still haven't seen that the new committe will actually achieve
anything of note. There seem to be be good signs, but we've been here
before...

> I understand the motivations for wanting
> things to be field-tested before making it into the report, but I
> don't think having a series of rapid incremental changes is the
> correct approach here. Because we're dealing with the Prelude and the
> core classes, the amount of breakage (and CPP used to paper over it)
> here is much higher than our usual treadmill of changes; so we should
> take that into account when planning how to roll the changes out.
>

This seems to be ignoring the huge amount of planning that actually
*did* go into this proposal (and the BPP, etc.).

No amount of planning can get around the fact that some people simply
*don't want any change*.