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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
243 messages Options
1234567 ... 13
Reply | Threaded
Open this post in threaded view
|

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

Manuel Gómez
On Fri, Oct 2, 2015 at 8:31 PM, Henrik Nilsson
<[hidden email]> wrote:
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.

Ah, success at the cost of warts.  I see our priorities as a community
have changed.

> Anyway, a discussion about the pros and cons of
> applicative do entitrely tangential to the point being
> made. The point is that applicative do is not yet part
> of any Haskell standard, and at this point it is not
> clear what any future syntactic support for applicative
> code will look like exactly. Therefore is premature to
> use this as an argument for this particular proposal,
> making any such an argument a weak one. Removal of
> "return" as a method of Monad can clearly wait until
> such time that syntactic support for applicative code
> makes it into the language, if it then is found that
> that support, whatever it looks like, would be
> unworkable without this change.
>
> …
>
> Bottom line: Breaking changes should only be adopted
> for very compelling reasons. The reasons put forward
> for far for "monad of no return" fails to meet that
> standard. Therefore it should not be adopted, at least
> not at this time.

`return` should have never been a part of the `Monad` type class.  It
does not belong there any more than `fail` does.  We could discuss (in
a separate thread) whether `pure` should be named `return`.  We could
likewise discuss whether it should be in some separate class like the
often-suggested `Point` with whatever name.  We could likewise discuss
where that class should lie in the hierarchy.

In a post-AMP Haskell, however, retaining `return` in `Monad` does not
serve any purpose: any `Monad` instance requires an `Applicative`
instance, wherein `pure` must be defined, and it is a law required by
all instances that they behave identically.  The only expressive
purpose of `return` being in the `Monad` type class is providing an
opportunity to break the laws the community expects for all instances
of `Monad`.

This community rightly values statically eliminating opportunities for
errors, and the removal of `return` as a method of `Monad` serves this
purpose.  This is reason alone to implement this proposal, even in the
absence of `ApplicativeDo`.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Henrik Nilsson-2

I take your concerns about unnecessary breaking changes seriously. And it is certainly true that a large amount of existing code will break. However, I am not at all convinced that the "mental weight" of this change is nearly as great as that of the now-accomplished AMP, in the presence of good error messages. Someone reading a classic article on Haskell who writes out their Monad instance will already be informed that they need to first cough up an instance of a class that article has no information about. An additional error message telling them to please delete a single binding hardly seems onerous in comparison.

I think removing error-prone redundancy is a good thing. While I expect there are few return/pure mismatches, they are certainly possible. The most likely scenario, I imagine, involves a difference in strictness when someone erroneously thinks they can get away with

Applicative f => Applicative (t f)

when in fact they need

Monad f => Applicative (t f)

to obey pure = return in that particular case.

On Oct 2, 2015 9:01 PM, "Henrik Nilsson" <[hidden email]> wrote:
Hi all,

Bardur Arantsson wrote:

> I should also say: I certainly *understand* the
> textbook argument, [...] but this is not a good
> *general* argument against change.

Just to be clear, Graham and I were not at all arguing
against change in general. But we are, in general,
urging extreme caution when it comes to non-essential
breaking changes.

Measuring breakage by referring to Hackage is just the
tip of the iceberg. Much breakage, including
proprietary code, books, research papers, what people
have learned, is very difficult or impossible to
measure. Somehow this point seems to have been
forgotten in the present discussion. The reason there
has to be really compelling reasons for adopting
breaking changes is exactly because the full impact of
those breaking changes is very hard to gauge properly. As
to this specific proposal, in our opinion, the reasons
put forward so far for the "monad of no return" are not
very compelling. And therefore it should not be adopted
at this point.

> Have you surveyed the actual number of books out
> there which show how to implement Monad instances and
> how many of them would be affected?

No. we have not. But ought not the burden of proof rest
with those who are proposing a non-essential breaking
change? If not, why not?

> but if we're going that way, then we're going to end
> up like C++... before C++11/C++14. [...] (stagnatiation)

We are hardly going to end up like C++ in that sense by
being very careful before adopting non-essential
breaking changes. Or even rule them out. Nor, returning
to this specific proposal, is leaving "return" as a
method of "Monad" going to mean that Haskell ends
up being stagnant.

Further, it is also worth noting that by almost any
measure C++ is an extremely successful language despite
its warts.

> "Verbose" is the understatement of the year. There's
> a lot of code where ApplicativeDo makes the
> difference between "readable" and "unreadable". Like
> it or not, but programmers are used to *naming
> things* (even locally) and using those local names to
> refer to things.

If so, suggesting that programmers necessarily want to
name things is the sweeping generalisation of the year.

For example, I have written quite a bit of applicative
code, way before it was even called applicative, and I
did not find the lack of syntactic support particularly
bothersome. On the other hand, I have also written a
lot of arrowized code, and there, while I do use the
syntactic sugar to allow me to name certain things, the
fact that I then have to name everything is rather
annoying to say the least, and I have often found
myself wishing that I could write arrowized code that
looked a lot more like applicative code (without the
sugar).

For a very different example, function composition,
maps, and folds are all examples of constructs
in common use where programmers opt to not name
intermediate things.

Anyway, a discussion about the pros and cons of
applicative do entitrely tangential to the point being
made. The point is that applicative do is not yet part
of any Haskell standard, and at this point it is not
clear what any future syntactic support for applicative
code will look like exactly. Therefore is premature to
use this as an argument for this particular proposal,
making any such an argument a weak one. Removal of
"return" as a method of Monad can clearly wait until
such time that syntactic support for applicative code
makes it into the language, if it then is found that
that support, whatever it looks like, would be
unworkable without this change.

Further, I reiterate that if people writing applicative
code were to use "pure" instead of "return", which does
not at all seem unreasonable, the stated problem goes
away. And such a change would clearly have far less
impact on legacy code, text books, teaching material,
what many programmers have learned simply by virtue of
the fact that Applicative in its current form is a very
recent addition.

Bottom line: Breaking changes should only be adopted
for very compelling reasons. The reasons put forward
for far for "monad of no return" fails to meet that
standard. Therefore it should not be adopted, at least
not at this time.

/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

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

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

Dominic Steinitz-2
In reply to this post by Herbert Valerio Riedel
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.
Thank you for articulating what are also my misgivings. -1 from me also.

On a historical note `return` used to be called `unit`.



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

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

Johan Tibell-2
-1 from me as well.

I don't find the proposal convincing.

Cons:
 * Major breakages to existing code (which needs to be updated), docs (many of which can't be updated), and future code (coding with ifdefs is error prone).

Pros:
 * A feeling of cleanliness.

I think there's an implicit argument being made here, that if we let time go towards infinity every breaking change is eventually paid off, no matter how small the gain. Time doesn't go to infinity for us. Haskell currently has a window of opportunity for being adopted and bringing more functional programmers to the world. This window isn't very big, perhaps a couple of years to a decade. If we make programming in Haskell annoying by continuously breaking anything, people will lose interest in Haskell and move on to other languages.

-- Johan


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

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

Henrik Nilsson-2
In reply to this post by Manuel Gómez
Hi all,

Manuel Gómez wrote:

 > > Further, it is also worth noting that by almost any
 > > measure C++ is an extremely successful language despite
 > > its warts.
 >
 > Ah, success at the cost of warts.  I see our priorities as a community
 > have changed.

That's nonsensical and unnecessarily polemic.

I am merely pointing out that removal of every single "wart" is
not a prerequisite for success. But striving for "perfection" can
have significant and even unjustifiable costs.

 > `return` should have never been a part of the `Monad` type class.

That's an odd statement. The mathematical concept of a monad
clearly does not necessitate structuring things as a hierarchy of
classes.

In any case, the point is that "return" has been part of "Monad"
for some 25 years. That's a serious historical legacy that should
not be dismissed lightly for reasons already discussed.

 > In a post-AMP Haskell, however, retaining `return` in `Monad` does not
 > serve any purpose:

That is not true. It does provide for an opportunity to write code
that works with versions of GHC prior to 7.10 as well as later versions
with a few fairly small fixes and (without resorting to conditional
compilation). That's important to some people.

 > This community rightly values statically eliminating opportunities for
 > errors, and the removal of `return` as a method of `Monad` serves this
 > purpose.  This is reason alone to implement this proposal, even in the
 > absence of `ApplicativeDo`.

While I do accept your point about a mostly redundant "return"
providing one opportunity to accidentally breaking a law that should
hold, *any* Monad instance provide an opportunity for breaking
multiple laws. Further, there are a range of classes where there
are methods with default instances that are there to provide
for an opportunity for more efficient implementation. They also
need to satisfy laws and again there is an opportunity for
accidentally breaking those.

I am thus hard pressed to believe that keeping "return" as a method
makes of Monad makes any perceptible practical difference either
way in that respect.

So, at least in my opinion, this is argument is no stronger
than those already put forward.

All the 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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Henrik Nilsson-2
In reply to this post by David Feuer
Hi all,

David Feuer wrote:

 > I take your concerns about unnecessary breaking changes seriously.
 > And it is certainly true that a large amount of existing code will
 > break. However, I am not at all convinced that the "mental weight" of
 > this change is nearly as great as that of the now-accomplished AMP,
 > in the presence of good error messages.

That may be true (and if pressed, I'd likely agree with you), but
it is beside the Graham and I were making: AMP does not necessitate
"monad of no return", and the cost of the additional breakage of
the latter should thus be justified in terms of how essential it is
for other reasons. At least there should be a very compelling
argument that the advantages clearly outweighs the costs. And again,
in any case like this, I think the burden of proof necessarily
rests with those who are arguing for the change.

 > I think removing error-prone redundancy is a good thing.

Undeniably. But does eliminating this particular
redundancy make enough of a practical difference to
justify the costs? There are plenty of opportunities
to break laws and introducing strictness bugs anyway.
See previous e-mail.

All the 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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Henrik Nilsson-2
In reply to this post by Johan Tibell-2
Hi all,

Johan Tibell wrote:

On 10/03/2015 09:00 AM, Johan Tibell wrote:
> Time doesn't go to infinity for us. Haskell currently has a window of
> opportunity for being adopted and bringing more functional programmers
> to the world. This window isn't very big, perhaps a couple of years to a
> decade. If we make programming in Haskell annoying by continuously
> breaking anything, people will lose interest in Haskell and move on to
> other languages.

Well said. That is also a major concern of Graham and myself.
And it is not just people considering adopting Haskell
who are being annoyed, but also long-standing members of
the community.

Just to give one data point, Graham tells me that the
latest revision of Richard Bird's Haskell book was
broken with respect to the latest changes before it
had had a chance to hit the shops. The changes that
broke the book may well have been essential. But such
breakage is clearly annoying to many people, including
those who have bought a recently updated book only
to find that it does not quite work.

We really need to be careful to not break things
unless absolutely necessary.

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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Bardur Arantsson-2
In reply to this post by Henrik Nilsson-2
On 10/03/2015 03:01 AM, Henrik Nilsson wrote:

> Hi all,
>
> Bardur Arantsson wrote:
>
>> I should also say: I certainly *understand* the
>> textbook argument, [...] but this is not a good
>> *general* argument against change.
>
> Just to be clear, Graham and I were not at all arguing
> against change in general. But we are, in general,
> urging extreme caution when it comes to non-essential
> breaking changes.
>
> Measuring breakage by referring to Hackage is just the
> tip of the iceberg. Much breakage, including
> proprietary code, books, research papers, what people
> have learned, is very difficult or impossible to
> measure. Somehow this point seems to have been
> forgotten in the present discussion. The reason there
> has to be really compelling reasons for adopting
> breaking changes is exactly because the full impact of
> those breaking changes is very hard to gauge properly. As
> to this specific proposal, in our opinion, the reasons
> put forward so far for the "monad of no return" are not
> very compelling. And therefore it should not be adopted
> at this point.
>
>> Have you surveyed the actual number of books out
>> there which show how to implement Monad instances and
>> how many of them would be affected?
>
> No. we have not. But ought not the burden of proof rest
> with those who are proposing a non-essential breaking
> change? If not, why not?
>
>> but if we're going that way, then we're going to end
>> up like C++... before C++11/C++14. [...] (stagnatiation)
>
> We are hardly going to end up like C++ in that sense by
> being very careful before adopting non-essential
> breaking changes. Or even rule them out. Nor, returning
> to this specific proposal, is leaving "return" as a
> method of "Monad" going to mean that Haskell ends
> up being stagnant.
>
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.
>

C++ is what "success at all cost" looks like. (I won't bother responding
to the rest, others have done that adequately.)

Look, I truly[1] do appreciate the arguments in favor of "don't break
things", but I don't think it's borne out by any reasonable reading of
history.

Regards,

[1] At least I think I do. :)

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

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

Jon Fairbairn
In reply to this post by Henrik Nilsson-2
Henrik Nilsson <[hidden email]> writes:

> Hi all,
>
> Johan Tibell wrote:
>
> On 10/03/2015 09:00 AM, Johan Tibell wrote:
>> Time doesn't go to infinity for us. Haskell currently has a window of
>> opportunity for being adopted and bringing more functional programmers
>> to the world. This window isn't very big, perhaps a couple of years to a
>> decade. If we make programming in Haskell annoying by continuously
>> breaking anything, people will lose interest in Haskell and move on to
>> other languages.
>
> Well said. That is also a major concern of Graham and myself.
> And it is not just people considering adopting Haskell
> who are being annoyed, but also long-standing members of
> the community.

That includes me. I have various pieces of software that I have
written in Haskell over the years, and having fiddle with them
pretty much every time there is a new release of ghc is very
irritating. Obviously I don’t bother to recompile most of them
every time, because one of the advantages of programming in
Haskell is that I make fewer mistakes: so the code works and has
done for years, but when I want to add a new feature or
compensate for some change in the environment, what should be a
10 minute job ends up taking ages.

-1 on the proposal.

--
Jón Fairbairn                                 [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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Henrik Nilsson-2
In reply to this post by Bardur Arantsson-2
Hi all,

Bardur Arantsson wrote:

On 10/03/2015 10:06 AM, Bardur Arantsson wrote:
> C++ is what "success at all cost" looks like. (I won't bother responding
> to the rest, others have done that adequately.)

Haskell is at no risk of becoming like C++ in that respect either.

The point being made was just that the odd wart is not a big problem.
But breaking things without really compelling reasons is.

> Look, I truly[1] do appreciate the arguments in favor of "don't break
> things", but I don't think it's borne out by any reasonable reading of
> history.

Again, Graham and I were not saying "don't break things". We were saying
"if things are to be broken, then there had better be very compelling
reasons".

That's a big difference.

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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Taru Karttunen
In reply to this post by Herbert Valerio Riedel
On 24.09 23:43, Herbert Valerio Riedel wrote:
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:

-1

Would providing automated tooling for changes be possible?

I think there would be much less resistance if there was working
automatic tooling for the various changes and e.g. >95% of Hackage
would build with each new GHC version.

Currently code seems to be breaking with every major GHC release.
In essence this drives up costs of maintaining software.

One of the reasons I use Haskell less than I used to use for
work stuff is the lack of stability and constant breakage
that adds up.

- 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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Imants Cekusins
> lack of stability and constant breakage

isn't this the case with most languages and frameworks, including the
most popular?

which is the real problem: changes themselves or libraries not being
maintained / upgraded?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andrés Sicard-Ramírez-2
In reply to this post by Herbert Valerio Riedel
Hi,

In Agda, we added support for GHC 7.10.* following the migration guide
available at

  https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10

In particular, we added instances of Applicative using

  instance Applicative Foo where
    pure  = return
    (<*>) = ap  -- defined in Control.Monad


After reading the "Monad of no `return` proposal" below, I have two questions:

1. Shouldn't the above migration guide to be changed to something like

  instance Applicative Foo where
    pure  = <copy-the-definition-of-return>
    ...

  instance Monad Foo where
    return = pure

?

2. Since in Agda code `return` is used everywhere, does follow (1) has
some performance cost?


All the best,


On 24 September 2015 at 16:43, Herbert Valerio Riedel <[hidden email]> wrote:

> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
>
> Current Situation
> -----------------
>
> With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and
> (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy
> becomes
>
>
>     class  Functor f  where
>         fmap    :: (a -> b) -> f a -> f b
>
>
>     class  Functor f => Applicative f  where
>         pure    :: a -> f a
>         (<*>)   :: f (a -> b) -> f a -> f b
>
>         (*>)    :: f a -> f b -> f b
>         u *> v  = …
>
>         (<*)    :: f a -> f b -> f a
>         u <* v  = …
>
>
>     class  Applicative m => Monad m  where
>         (>>=)   :: m a -> (a -> m b) -> m b
>
>         return  :: a -> m a
>         return  = pure
>
>         (>>)    :: m a -> m b -> m b
>         m >> k  = …
>
>
>     class  Monad m => MonadFail m  where
>         fail    :: String -> m a
>
>
> Consequently, the `Monad` class is left with a now redundant `return`
> method as a historic artifact, as there's no compelling reason to
> have `pure` and `return` implemented differently.
>
> Traditionally, `return` is often used where `pure` would suffice
> today, forcing a `Monad` constraint even if a weaker `Applicative`
> would have sufficed.
>
> As a result, language extensions like `ApplicativeDo`[3] have to
> rewrite `return` to weaken its `Monad m =>` constraint to
> `Applicative m =>` in order to benefit existing code at the cost
> of introducing magic behavior at the type level.
>
> Finally, this redundancy becomes even more significant when viewed in
> light of the renewed Haskell standardisation process[7]: The next
> Haskell Report will almost certainly incorporate the AMP (and MFP)
> changes, and there's no justification for the Report to retain
> `return` as a method of `Monad`. A good reason would have been to
> retain backward compatibility with Haskell 2010. However, as the AMP
> superclass hierarchy requires `Monad` instances to be accompanied by
> `Applicative` instances (which aren't part of Haskell 2010, c.f. [6]),
> backward compatibility with Haskell 2010 goes out the window when it
> comes to defining `Monad` instances (unless via use of `-XCPP` or
> similar).  Consequently, meeting the high bar for a formal document
> such as the Haskell Report demands that `Monad` shall not carry a
> redundant `return` method that serves no purpose anymore. Moreover,
> getting `return` out of the way is desirable to facilitate
> standardising potential candidates such as the earlier mentioned
> `ApplicativeDo` in the future and avoids the technical debt incurred
> by keeping around this language wart.
>
>
> Proposed Change
> ---------------
>
> Remove `return` as a method from the `Monad` class and in its place
> define a top-level binding with the weaker `Applicative` typeclass
> constraint:
>
>
>     -- | Legacy alias for 'pure'
>     return :: Applicative f => a -> f a
>     return = pure
>
>
> This allows existing code using `return` to benefit from a weaker
> typeclass constraint as well as cleaning the `Monad` class from a
> redundant method in the post-AMP world.
>
> A possible migration strategy is described further below.
>
>
> Compatibility Considerations
> ----------------------------
>
> Generalizing the type signature of a function from a `Monad`
> constraint to its superclass `Applicative` doesn't cause new
> type-errors in existing code.
>
> However, moving a method to a top-level binding obviously breaks code
> that assumes `return` to be a class method. Foremost, code that
> defines `Monad` instances it at risk:
>
> ### Instance Definitions
>
> Code defining `return` as part of an instance definition
> breaks. However, we had the foresight to provide a default
> implementation in `base-4.8` for `return` so that the following
> represents a proper minimal instance definition post-AMP:
>
>
>     instance Functor Foo where
>         fmap g foo  = …
>
>     instance Applicative Foo where
>         pure x      = …
>         a1 <*> a2   = …
>
>     instance Monad Foo where
>         m >>= f     = …
>
>         -- NB: No mention of `return`
>
>
> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.
>
> Heuristically `grep`ing through Hackage source-code reveals a
> non-negligible number of packages defining `Monad` instances with
> explicit `return` definitions[4]. This has a comparable impact to the
> AMP, and similarly will require a transition scheme aided by compiler
> warnings.
>
> ### Module Import/Export Specifications
>
> A second source of incompatibility may be due to
> `import`s. Specifically module import that assert `return` to be a
> method of `Monad`, e.g.:
>
>     import Control.Monad  (Monad ((>>=), return))
>
> or
>
>     import Prelude hiding (Monad(..))
>     import Control.Monad  (Monad(..)) as Monad
>
>     f = Monad.return ()
>
> The dual situation can occur when re-exporting `return` via module
> export specifications.
>
> However, given that `return` is exported by `Prelude` and the examples
> above are rather artificial, we don't expect this to be a major source
> of breakage in the case of `return`. In fact, a heuristic grep[5] over
> Hackage source-code revealed only 21 packages affected.
>
> ### Example for writing compatible code
>
>
>     instance Functor Foo where
>         fmap g foo  = …
>
>     instance Applicative Foo where
>         pure x      = …
>         a1 <*> a2   = …
>
>     instance Monad Foo where
>         m >>= f     = …
>
>     #if !(MIN_VERSION_base(4,8,0))
>         return = pure
>     #endif
>
>
> Migration Strategy
> ------------------
>
> The migration strategy is straightforward:
>
> **Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets
>    triggered when `Monad` instances explicitly override the
>    default `return` method implementation.
>
> **Phase 2** *(GHC 8.2 or later)*: When we're confident that the
>    majority of Hackage has reacted to the warning (with the help of
>    Stackage actively pursuing maintainers to update their packages) we
>    turn the `return` method into a top-level binding and remove the
>    warning implemented in Phase 1 from GHC again.
>
>
> Discussion period
> -----------------
>
> A discussion period of three weeks (until 2015-10-15) should be enough
> to allow everyone to chime in as well as leave enough time to make the
> required preparations for GHC 8.0 should this proposal pass as we hope.
>
> ----
>
>  [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
>  [2]: https://wiki.haskell.org/MonadFail_Proposal
>  [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
>  [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9
>  [5]: https://gist.github.com/hvr/afcd040783d980594883
>  [6]: https://ghc.haskell.org/trac/ghc/ticket/9590
>  [7]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html
>
> --
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



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

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

> Again, Graham and I were not saying "don't break things". We were saying "if
> things are to be broken, then there had better be very compelling reasons".

> That's a big difference.

You made a great argument, Henrik, and you've changed my enthusiastic +1 to
+0, until it can be bundled with some other, more necessary, breaking 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: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

Herbert Valerio Riedel
In reply to this post by Henrik Nilsson-2
On 2015-10-03 at 03:01:12 +0200, Henrik Nilsson wrote:

[...]

>> Have you surveyed the actual number of books out
>> there which show how to implement Monad instances and
>> how many of them would be affected?
>
> No. we have not. But ought not the burden of proof rest
> with those who are proposing a non-essential breaking
> change? If not, why not?

Well, afaik the books commonly used in teaching are largely based on
Haskell 98 or Haskell 2010.

( IMO, the problem here is rather the expectation that the latest GHC
  would still provide a Haskell 2010 library environment, even though
  the few books based on GHC for the most part let the reader run GHC in
  default mode and mention neither `-XHaskell2010` nor `-package
  haskell2010`.  And yes, GHC 7.10 effectively had to drop support for
  `-package haskell2010`. Otoh, There's several Linux distributions
  still stuck on GHC 7.6.3 (e.g. Debian & Ubuntu) or even older.
   
  Btw, would the concern be addressed if a future GHC would recover a
  legacy Haskell2010 library environment?
)

All books I've looked at so far will undoubtedly have their examples
defining `Monad` instances be broken under the next Haskell Report, even
*without* the MRP which simplifies the Haskell Report and is surely more
desirable from a pedagogical point of view as well.

----------------------------------------------------------------------------

For instance, in Graham Hutton's Book the section about defining Monad
instances in chapter 10[1] is rather short (defining `Monad` instances
is not an essential part of that book) and presents the Monads
type-class literally as

  class Monad m where
     return :: a -> m a
     (>>=)  :: m a -> (a -> m b) -> m b

and goes on to claim

| Using this declaration, parsers and interactive programs can then be
| made into instances of the class of monadic types, by defining the two
| member functions in the appropriate manner:

And this will clearly not apply anymore under the next Haskell Report.
On the bright side, `fail` is not mentioned, so at least it won't break
under the MonadFail change.

----

Richard Bird's "Thinking Functionally with Haskell" from 2014 sticks to
Haskell2010, and presents the `Monad` class exactly like Graham's book
(i.e. providing only `return` and `(>>=)`). Curiously, even though
published in 2014, `Applicative` isn't mentioned anywhere in the
book. In any case, this Book's `Monad`-instance examples will be broken
as well under a new Haskell Report due to the AMP change.

----

Simon Thompson's "Haskell - the Craft of Functional Programming, 3ed"
(2011), on the other hand presents the `Monad` class exactly as written
into the Haskell 2010 Report, namely:


   class Monad m where
    (>>=)   :: m a -> (a -> m b) -> m b
    return  :: a -> m a
    (>>)    :: m a -> m b -> m b
    fail    :: String -> m a

    m >> k  =  m >>= \_ -> k
    fail s  = error s


Consequently, `Monad`-defining examples in that book break on accounts
of both, AMP *and* MonadFail changes.

----

The "Real World Haskell" book predates Haskell 2010 by a few years but
features the `Applicative` class. `Monad`-instance examples contained in
the book break on accounts of AMP and MonadFail as well.

----

Miran Lipovaca's very popular "Learn You a Haskell for Great Good" (2011)
book is written in a more casual style and targets mostly Haskell
2010. The `Monad` class is presented with the 4 methods according to the
Haskell 2010 Report.[2]

The `Applicative` class is mentioned and the missing superclass
relationship is pointed out:

| Shouldn't there be a class constraint in there along the lines of
| `class (Applicative m) => Monad m where` so that a type has to be an
| applicative functor first before it can be made a monad? Well, there
| should, but when Haskell was made, it hadn't occured to people that
| applicative functors are a good fit for Haskell so they weren't in
| there.

It's also noteworthy that the book has to explain why there are two
different verbs for the same purpose:

| The first function that the Monad type class defines is `return`. It's
| the same as `pure`, only with a different name. Its type is `(Monad m)
| => a -> m a`. It takes a value and puts it in a minimal default
| context that still holds that value. In other words, it takes
| something and wraps it in a monad. It always does the same thing as
| the `pure` function from the `Applicative` type class, which means
| we're already acquainted with `return`. We already used `return` when
| doing I/O. We used it to take a value and make a bogus I/O action that
| does nothing but yield that value.

The `MonadFail` class, however, is neither mentioned nor anticipated. So
LYAH will need to be updated as well regarding AMP and MonadFail induced
breakages.

----

Finally, Alejandro Serrano Mena's more practical "Beginning Haskell" book
also provides to the full Haskell 2010 `Monad` class
definition. The `Applicative` class is described as well. However, the
book was clearly written in the knowledge of the upcoming AMP:

| If any Monad instance is also an instance of Functor, why is this
| relation not shown in the declaration of those classes? This is a
| historical accident, and you should expect Functor to soon become a
| superclass of Monad . In the meantime, you should ensure that you have
| an instance of Functor for each of your Monad instances: you can build
| one easily using the aforementioned liftM function.

as well as

| The fact that Applicative does not appear as a superclass of Monad is
| again a historical accident: the Monad concept was used widely much
| earlier than the concept of Applicative . For compatibility reasons,
| Monad hasn’t changed its definition to include any of Functor or
| Applicative as superclasses. This will change soon, though, and the
| full hierarchy Functor , then Applicative , then Monad will be
| apparent in the type classes.

But at the time of writing the MonadFail proposal couldn't be
foreseen.

----------------------------------------------------------------------------

These may not be all the Haskell books out there, but these examples
clearly show that we've already set a precedent with the AMP and the
MonadFail proposal alone. There are a few other base-library transitions
already happened or in mid-flight that have a similar effect on
published books and materials which leave the boundaries of the Haskell
2010 Library Report.

So if the primary argument is that published literature shouldn't get
broken. Well, that's already happened. And there will unavoidably be
incompatible changes between Haskell2010 and Haskell201x.


The point of this Monad-of-no-return Proposal was to provide the formal
basis to be able to write the AMP into the next upcoming Haskell Report
in a sensible way (and I think we can all agree that this is the right
thing to do as there is no good justification for including the
`Monad(return)`-method in an Haskell Report integrating the AMP changes)


However, one thing that seems to have been mostly ignored in this whole
discussion so far is that just because the next Haskell Report
anticipates the removal of `return` and `(>>)` as methods this doesn't
mean that GHC's `base` library has to follow suit immediately!

The proposal states that phase 2 can happen in GHC 8.2 *or later*. This
could also mean e.g. GHC 8.4, GHC 8.8, or even GHC 9.0!  This is very
different from the AMP, MFP or FTP which are/were subject to a swift
transition scheme with a rigid timeframe.

Old code still overriding `return` will continue to compile (if it
didn't break already for AMP/MFP/...) for as many years in GHC as
desired.

And code written against the new Haskell Report (especially when
ignoring the existence of the `return`-method) would work just fine
against GHC's `base` as well.

So there's not that much immediate breakage due to MRP specifically
after all.


Regards,
  H.V.Riedel

 [1]: http://i.imgur.com/DyPTZml.png
 [2]: http://learnyouahaskell.com/a-fistful-of-monads#the-monad-type-class
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Wiegley-2
>>>>> Herbert Valerio Riedel <[hidden email]> writes:

> The point of this Monad-of-no-return Proposal was to provide the formal
> basis to be able to write the AMP into the next upcoming Haskell Report in a
> sensible way (and I think we can all agree that this is the right thing to
> do as there is no good justification for including the
> `Monad(return)`-method in an Haskell Report integrating the AMP changes)

> However, one thing that seems to have been mostly ignored in this whole
> discussion so far is that just because the next Haskell Report anticipates
> the removal of `return` and `(>>)` as methods this doesn't mean that GHC's
> `base` library has to follow suit immediately!

> The proposal states that phase 2 can happen in GHC 8.2 *or later*. This
> could also mean e.g. GHC 8.4, GHC 8.8, or even GHC 9.0! This is very
> different from the AMP, MFP or FTP which are/were subject to a swift
> transition scheme with a rigid timeframe.

> Old code still overriding `return` will continue to compile (if it didn't
> break already for AMP/MFP/...) for as many years in GHC as desired.

> And code written against the new Haskell Report (especially when ignoring
> the existence of the `return`-method) would work just fine against GHC's
> `base` as well.

> So there's not that much immediate breakage due to MRP specifically after
> all.

Then count me again as +1, thanks for the clarification, Herbert.

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

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

Herbert Valerio Riedel
In reply to this post by Andrés Sicard-Ramírez-2
Hello,

On 2015-10-03 at 16:43:53 +0200, Andrés Sicard-Ramírez wrote:

> In Agda, we added support for GHC 7.10.* following the migration guide
> available at
>
>   https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10
>
> In particular, we added instances of Applicative using
>
>   instance Applicative Foo where
>     pure  = return
>     (<*>) = ap  -- defined in Control.Monad
>
>
> After reading the "Monad of no `return` proposal" below, I have two questions:
>
> 1. Shouldn't the above migration guide to be changed to something like
>
>   instance Applicative Foo where
>     pure  = <copy-the-definition-of-return>
>     ...
>
>   instance Monad Foo where
>     return = pure
>
> ?

Indeed, I've updated the GHC wiki page accordingly, thanks for pointing
that out!

> 2. Since in Agda code `return` is used everywhere, does follow (1) has
> some performance cost?

If you have generic code which doesn't get specialised to a specific
class dictionary for Monad/Applicative then there's the overhead of an
additional indirection (depending on which way around the
Monad/Applicative instances were defined).

The AMP instructions were formulated in a way to make manual refactoring
easiest, while they don't necessarily match how you'd define instances
from scratch in a post-AMP setting.

Given the convenience of the post-AMP default-method-implementation of
`return`, I expect new code to start defining `return` in terms of
`pure` rather than the other way around, and older existing code will
probably slowly migrate to that state as well.

Given the usual 3-major-GHC-version compatibility window convention we
strive for in Hackage-released Haskell code, starting with GHC 8.2, code
written not defining `return` explicitly anymore will be compliant with
this convention.

In any case, if you *know* that you incur an overhead if you use
`return` rather than `pure` in your code (due to
e.g. non-specialisation) and don't want to refactor your code just yet
to use `pure` instead of `return`, you can hide the import of `return`
and define an inlineable `return = pure` top-level binding in its
place. Otoh, if you have code which doesn't specialise the
Monad-instances I'd expect the `return`-induced overhead to be a minor
contribution as GHC will have already missed a few other opportunities
to inline and optimise your code.

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

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

Thomas Miedema
In reply to this post by Herbert Valerio Riedel
> So there's not that much immediate breakage due to MRP specifically after
> all.

Then count me again as +1, thanks for the clarification, Herbert.

+1 as well

- The books are already outdated. Libraries can be updated.
- This proposal simplifies the language and the next Haskell report.

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

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

Ben Gamari-2
In reply to this post by Herbert Valerio Riedel
Herbert Valerio Riedel <[hidden email]> writes:

> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
+1

With a sufficiently long timeframe for adoption (with removal no earlier
than 8.4) it seems like the immediate cost of this change shouldn't be
so onerous; if we managed AMP then we should be able to pull this off as
well. It seems to be the right thing to do and I sincerely believe we
can keep the cost to users low; let's do it.

I find this especially true in light of the recent advances made in the
area of tooling. We are now in a much better position to be offering
tools for automated refactoring than we were even when we considered
AMP. Perhaps one of the HaRe contributors can comment on the feasibility
of automatically rewriting `return` definitions to `pure` definitions?
It feels like this should be quite workable in most cases.

It also helps that we have the luxury of being able to pick this change up
at a relaxed pace. For a long time, we as a community have lamented the
lack of tools (both language features and otherwise) for restructuring
typeclass hierarchies (e.g. see #4879, #2119, #10071). Since we now have
the experience of AMP under our collective belts, it seems like we are
in a much better position to put forward some concrete proposals for
easing this sort of interface refactoring and deprecation.

The `DEPRECATED`/`REMOVED` pragmas on class methods would be a great
step towards this end. With a bit of work we could greatly reduce the
impact of changes like these; an improvement that could bring benefits
well beyond the core libraries. Those interested in contributing in this
area should see the Wiki [1].

With respect to invalidating teaching materials, I think this ship has
already sailed with AMP and `MonadFail`, as Herbert has pointed out.
Nevertheless we can help their users evolve along with the language with
deprecation mechanisms, tools, and approachable error messages.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Design/DeprecationMechanisms

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

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Greg Weber
1) I would like to ban the usage of the term "C++" in all libraries mailing list discussions except for those discussing binding C++ code. I have never seen intelligent discussion result from bringing up "C++" in an unrelated context.
2) Is there an updated wiki page for this proposal that explains the migration path for the community

It seems that there is a lot of discussion about what this proposal might be and it is time to make it more concrete (particularly with respect to how exactly library and application authors handle breakage) if there is going to be more productive conversation going forward.
Also, one should not be required to re-read this long thread and pick out important details to understand the proposal as it exists now.


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