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

Henrik Nilsson Henrik.Nilsson at nottingham.ac.uk
Sat Oct 3 08:09:52 UTC 2015


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
nhn at cs.nott.ac.uk




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

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

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



More information about the Libraries mailing list