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

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

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

Richard Eisenberg-2

On Sep 27, 2015, at 6:22 PM, David Luposchainsky <[hidden email]> wrote:

> On 28.09.2015 00:16, David Feuer wrote:
>> For the benefit of people trying out code from papers, tutorials, etc., would it
>> be possible to craft a permanent custom error message for explicit return
>> definitions? I don't remember AMP having such for the new constraint; if it
>> doesn't, maybe it should.
>
> Sure, that's something we can probably do. I've done some (futile) digging in
> GHC, but the plan is to implement this as a "if a Monad definition contains a
> binding referring to 'return' emit a warning", which is or can be made orthogonal
> of there actually being a "return" in the actual class.

I like this idea -- I, for one, often forget to consider the effect legacy written material has. But if we're doing this for Monad, why not just come up with a pragma so that the magic doesn't have to be baked in? As in, witness the new definition for Monad:

> class Applicative m => Monad m where
>   ...
>   {-# REMOVED return "The `return` method has been removed from Monad. Use `pure` in Applicative instead" #-}

(Please fix my warning text.)

We people with direct access to GHC might not be the only ones who want to refactor a method out from a class.

Richard

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

David Feuer


On Sep 27, 2015 9:56 PM, "Richard Eisenberg" <[hidden email]> wrote:
>
> I like this idea -- I, for one, often forget to consider the effect legacy written material has. But if we're doing this for Monad, why not just come up with a pragma so that the magic doesn't have to be baked in? As in, witness the new definition for Monad:
>
> > class Applicative m => Monad m where
> >   ...
> >   {-# REMOVED return "The `return` method has been removed from Monad. Use `pure` in Applicative instead" #-}
>
> (Please fix my warning text.)
>
> We people with direct access to GHC might not be the only ones who want to refactor a method out from a class.

That's an excellent idea, and I think it makes sense to offer it at the module level as well as the class level. Just change DEPRECATED to REMOVED when it's actually removed. Speaking of such, has the deprecated export proposal made any headway?

David Feuer


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

Status of deprecation/warning features (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

Herbert Valerio Riedel
On 2015-09-28 at 04:56:13 +0200, David Feuer wrote:

[...]

> That's an excellent idea, and I think it makes sense to offer it at the
> module level as well as the class level. Just change DEPRECATED to REMOVED
> when it's actually removed. Speaking of such, has the deprecated export
> proposal made any headway?


As far as the in-flight library proposals are concerned, I plan to
rather have hardwired specific warnings implemented in the style of the
AMP warnings as it's crucial to have them available for the GHC 8.0
release to have the foundations for the migration plans in place. We can
generalize those feature later-on (maybe even in time for GHC 8.0 if
we're lucky).

----

As for the more general facilities the short answer is:

  They're stalled! Volunteers wanted!


There's the specification over at

 - https://ghc.haskell.org/trac/ghc/wiki/Design/MethodDeprecations

and there are 3 somewhat connected/related warning-feature tickets which
ought to be co-designed to avoid obstructing each other (if there's any
risk there).

 - https://ghc.haskell.org/trac/ghc/ticket/10071
 - https://ghc.haskell.org/trac/ghc/ticket/2119
 - https://ghc.haskell.org/trac/ghc/ticket/4879

For #10071 there's a very modest start at implementing this, which
just modifies the parser but doesn't go much farther (see wip/T10071 branch)

There's an old patch for #4879 which still works over at

 - https://phabricator.haskell.org/D638


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`

John Lato-2
In reply to this post by Richard Eisenberg-2
IME the community has a group that's highly skeptical of breaking changes with little-to-no benefit.  Renaming either pure or return I think would qualify, as the breakage would be extensive, and the resulting language would be identical modulo the renaming, i.e. no extra expressiveness is granted.  AMP addressed a long-standing pain point of the language and had a well-thought-out transition scheme, and Typeable is only rarely used by hand so the breakage wasn't actually that extensive.

My biggest concern with this proposal is the breakage of mostly-unmaintained but working packages.  As with ekmett, I'm in favor provided that there's a sufficiently well-planned transition period.  Providing a minor ghc release that warns about any superfluous 'return' definitions would be very helpful.

On Sat, Sep 26, 2015 at 5:05 PM Richard Eisenberg <[hidden email]> wrote:
Thanks for making this proposal.

I'm leery of the breakage that this would cause. But, there has been no chorus of voices complaining about breaking changes in the recent past (AMP and changes to Typeable are top on my mind), so perhaps our community is more tolerant of breakage than I would guess.

Given that, I'm +1 on this.

The one point of this proposal that's gotten some debate is preferring `pure` or preferring `return`. (I'm considering any contemplation of other names to be more noise than signal. Besides, I interpret most [all?] of those emails to be in varying degrees of jest.)

I vote for `pure` over `return`. Although some have pointed out that `return` feels more natural to those coming from other languages, it is a false friend [1]. `return` is emphatically not a language construct in Haskell, and it has no effect on flow control. On the other hand `pure` embeds a pure bit in an effectful computation. When I say do { x ; pure $ y }, `y` is indeed pure, as the function suggests. I think this is a much simpler approach than trying to convince skeptical Java programmers that `return` is nothing special.

Richard

[1]: https://en.wikipedia.org/wiki/False_friend

On Sep 24, 2015, at 5:43 PM, 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

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

wren romano-2
In reply to this post by Richard Eisenberg-2
On Sat, Sep 26, 2015 at 6:04 PM, Richard Eisenberg <[hidden email]> wrote:
> Thanks for making this proposal.
>
> I'm leery of the breakage that this would cause. But, there has been no chorus of voices complaining about breaking changes in the recent past (AMP and changes to Typeable are top on my mind), so perhaps our community is more tolerant of breakage than I would guess.

Though I'd love to see pure/return unified, I almost wonder if it'd be
a good idea to wait a bit on this. By which I mean, rather than having
a bunch of little breaking changes as we try to fix things piecemeal,
perhaps it'd be better to fold this proposal (and similar ones) into
the next Haskell' report (assuming we can actually ship it this time).
That way we can just have a big break-the-world change in the
transition to Haskell2020 (or whatever).

Not sure if that's the best approach, especially given the difficulty
in getting Haskell2020 finalized, but it might be worth thinking
about...

--
Live well,
~wren
_______________________________________________
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`

Malcolm Wallace-2
+1

 Regards,
    Malcolm (iPhone)

On 28 Sep 2015, at 22:42, wren romano <[hidden email]> wrote:

> On Sat, Sep 26, 2015 at 6:04 PM, Richard Eisenberg <[hidden email]> wrote:
> Thanks for making this proposal.
>
> I'm leery of the breakage that this would cause. But, there has been no chorus of voices complaining about breaking changes in the recent past (AMP and changes to Typeable are top on my mind), so perhaps our community is more tolerant of breakage than I would guess.

Though I'd love to see pure/return unified, I almost wonder if it'd be
a good idea to wait a bit on this. By which I mean, rather than having
a bunch of little breaking changes as we try to fix things piecemeal,
perhaps it'd be better to fold this proposal (and similar ones) into
the next Haskell' report (assuming we can actually ship it this time).
That way we can just have a big break-the-world change in the
transition to Haskell2020 (or whatever).

Not sure if that's the best approach, especially given the difficulty
in getting Haskell2020 finalized, but it might be worth thinking
about...

--
Live well,
~wren
_______________________________________________
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`

Edward Kmett-2
In reply to this post by wren romano-2
The standard is pretty much what was driving the timing of this proposal.

With warnings put in place in 8.0, we can have the situation set up so that this process completes in time for a Haskell 2017 that incorporates much of the current state of the world, AMP, Foldable/Traversable, etc.

Then knock-on effects like Traversable simplification can be in place by a Haskell 2020, which can try to be more ambitious.

If we don't start it now, however, then we won't have sufficient warning time for users.

On Mon, Sep 28, 2015 at 5:42 PM, wren romano <[hidden email]> wrote:
On Sat, Sep 26, 2015 at 6:04 PM, Richard Eisenberg <[hidden email]> wrote:
> Thanks for making this proposal.
>
> I'm leery of the breakage that this would cause. But, there has been no chorus of voices complaining about breaking changes in the recent past (AMP and changes to Typeable are top on my mind), so perhaps our community is more tolerant of breakage than I would guess.

Though I'd love to see pure/return unified, I almost wonder if it'd be
a good idea to wait a bit on this. By which I mean, rather than having
a bunch of little breaking changes as we try to fix things piecemeal,
perhaps it'd be better to fold this proposal (and similar ones) into
the next Haskell' report (assuming we can actually ship it this time).
That way we can just have a big break-the-world change in the
transition to Haskell2020 (or whatever).

Not sure if that's the best approach, especially given the difficulty
in getting Haskell2020 finalized, but it might be worth thinking
about...

--
Live well,
~wren
_______________________________________________
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`

S. Doaitse Swierstra
In reply to this post by wren romano-2

> On 25 Sep 2015, at 20:47 , wren romano <[hidden email]> wrote:
>
> On Fri, Sep 25, 2015 at 1:23 AM, Bardur Arantsson <[hidden email]> wrote:
>> Reasoning: I happen to rather like "return" for purely pedagogical
>> purposes since it lets you pretend (as a sufficient-for-beginners
>> approximation) that code in the do-notation in IO is imperative code and
>> "return" is the usual name for what it does in that context.

Like in

do a <- return 5
   b <- return 3
   return (a+b)

I think that calling pure return was a big mistake from the very beginning,

 Doaitse


>> I think
>> that has a certain value, but "Legacy" is quite off-putting.
>
> +1.
>
> I like the proposal to merge pure/return into a single thing, but I
> rather prefer the name "return" for all the same pedagogical reasons
> it was originally chosen.
>
> --
> Live well,
> ~wren
> _______________________________________________
> 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
|

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

Henning Thielemann
In reply to this post by David Feuer

On Sun, 27 Sep 2015, David Feuer wrote:

> On Sep 27, 2015 9:56 PM, "Richard Eisenberg" <[hidden email]> wrote:
> >
> > I like this idea -- I, for one, often forget to consider the effect legacy written material has. But if we're doing
> this for Monad, why not just come up with a pragma so that the magic doesn't have to be baked in? As in, witness the new
> definition for Monad:
> >
> > > class Applicative m => Monad m where
> > >   ...
> > >   {-# REMOVED return "The `return` method has been removed from Monad. Use `pure` in Applicative instead" #-}
> >
> > (Please fix my warning text.)
> >
> > We people with direct access to GHC might not be the only ones who want to refactor a method out from a class.
>
> That's an excellent idea, and I think it makes sense to offer it at the module level as well as the class level. Just
> change DEPRECATED to REMOVED when it's actually removed. Speaking of such, has the deprecated export proposal made any
> headway?
I like the idea of a REMOVED pragma very much. After a deprecated function
is actually removed it is hard to find out how to fix the code. I often
ignore DEPRECATED warnings because respecting them would break my code for
older GHC versions.
_______________________________________________
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`

Henning Thielemann
In reply to this post by Herbert Valerio Riedel

On Thu, 24 Sep 2015, Herbert Valerio Riedel wrote:

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

I do not see why this proposal is necessary and urgent. Over the past
years several redundant methods where added to type classes in order to
allow for optimized implementations. Without much investigation I remember
Foldable.sum, Foldable.product, ..., Applicative.*>, Applicative.<*,
Functor.<$, Bits.zeroBits and discussions about Monad.join. Although I
think that it is never possible to implement 'return' more efficiently
than 'pure', we could pretend for now that it is possible. :-) At least,
leaving 'return' does not hurt much.

My practical concern is that the change will break every current Monad
instance for no benefit and I would not be able to write code that works
for current and past GHC versions.


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

Like Henrik Nilsson, I wonder why people cannot replace 'return' by 'pure'
if they want to make use of ApplicativeDo. I think the people who want a
new feature should adapt their code. Why should I break my Monad instances
instead?


> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.

Because the completely unrelated bug [1] affects several of my packages, I
can use forward-compatible instances only starting with GHC-8.0.

Bugs like this one also underline why it is so important to write code
that works across multiple versions of GHC. Otherwise it's easily possible
that a program depends on a set of packages that cannot be compiled by any
GHC version.

If you are very keen to remove 'return' I would ask you to wait some more
release cycles of GHC.


[1] https://ghc.haskell.org/trac/ghc/ticket/10009
_______________________________________________
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 Luposchainsky
On 01.10.2015 19:03, Henning Thielemann wrote:
> Over the past years
> several redundant methods where added to type classes in order to allow for
> optimized implementations.

There's an important difference: *> is redundant, but not superflous. return on
the other hand offers zero new functionality.

> At least, leaving 'return' does not hurt much.

I guess that's a matter of what we want the standard to be. I think it should be
the guideline to "a good Haskell" that compilers should aim to implement. If it
takes GHC a couple of releases to become Report compliant then that's something
I'm OK with.

> My practical concern is that the change will break every current Monad instance
> for no benefit and I would not be able to write code that works for current and
> past GHC versions.

Monad instances written before 7.8. As of 7.10, return is not part of the minimal
definition of Monad anymore, so starting with the current release, you're already
able to write future-proof instances. That said, the issue with GHC < 7.10
remains of course.

> If you are very keen to remove 'return' I would ask you to wait some more release
> cycles of GHC.

Of course! The next release will do nothing but issue (a disable-able) warning
when an instance implements return. Beyond that, who knows, but it surely won't
be breaking half of `cabal build` because of impatience.

Greetings,
David/quchen

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




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
On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
> Hi all,
>
[--snip--]

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

"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.
"Random" combinations of <$> and/or <*> and/or... (whatever) with no
concrete meaningful names don't really work if you're working with
concrete CRUD-like data. (Fine, if you're working with very abstract
things then you might not even have meaningful names and so they lose
their value. This is *not* the universal experience.)

I should also say: I certainly *understand* the textbook argument, but
if we're going that way, then we're going to end up like C++... before
C++11/C++14. The C++ community/committee have realised their mistake
(stagnatiation) and resolved to instead produce more/better/newer
textbooks. For the better, IMO. We can certainly argue over individual
changes, but this is not a good *general* argument against change. 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?

Regards,

_______________________________________________
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
speaking not about this particular "return" issue but change as such:

change can be
a) avoided or
b) accommodated.

let's think of abstract languages L and N. Any resemblance is
coincidental and irrelevant.


Suppose that:

a significant codebase written in L is available

N is a new language with few libraries

a beginner programmer A.B. considers to dedicate their time and effort
to either L or N
A.B. prefers (for various reasons) N syntax.

an experienced programmer C.D. dedicated their time to L language.
C.D. is comfortable with L, wrote and use L code. C.D. can see some
advantages language N gives over L.

the number of programmers similar to C.D. (the L crowd) is fairly
stable but who knows: C.D. may join the N crowd.

number of A.B. and other undecided programmers varies. The more are
A.B.'s, the larger is future camp of any language: L, N, ...

let's think. This is not to argue pro/con but to put things in
perspective. If you were in A.B.'s shoes, what would you 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`

Mario Blažević
In reply to this post by Bardur Arantsson-2
On 15-10-02 04:50 PM, Bardur Arantsson wrote:

> On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
>> Hi all,
>>
> [--snip--]
>> 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.
>
> "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.

        Naming of applicative sub-expressions is perfectly doable without
reaching for any syntactic sugar. An applicative do like

        do a <- f long expression
            b <- g long expression
            return (h a b)

would be equivalent to

         let a = f long expression
             b = g long expression
          in f <$> a <*> b

        The benefits of applicative do, if I understand the motivation
correctly, are not so much to help in writing new code intended to be
applicative. Instead it lets the programmer write in monadic style and
at the same time enables the compiler to convert the code to applicative
style if possible. This has the potential to automatically improve
performance of legacy Haskell codebase, as well as any new
beginner-friendly code that relies on syntactic sugar.

        As for the issue of textbooks, I assume they describe Haskell 98. Until
Haskell compilers start defaulting to Haskell 2020 there shouldn't be
any issue.


_______________________________________________
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
On 10/02/2015 11:55 PM, Mario Blažević wrote:

> On 15-10-02 04:50 PM, Bardur Arantsson wrote:
>> On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
>>> Hi all,
>>>
>> [--snip--]
>>> 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.
>>
>> "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.
>
>     Naming of applicative sub-expressions is perfectly doable without
> reaching for any syntactic sugar. An applicative do like
>
>     do a <- f long expression
>            b <- g long expression
>            return (h a b)
>
> would be equivalent to
>
>         let a = f long expression
>             b = g long expression
>          in f <$> a <*> b
>
>     The benefits of applicative do, if I understand the motivation
> correctly, are not so much to help in writing new code intended to be
> applicative. Instead it lets the programmer write in monadic style and
> at the same time enables the compiler to convert the code to applicative
> style if possible. This has the potential to automatically improve
> performance of legacy Haskell codebase, as well as any new
> beginner-friendly code that relies on syntactic sugar.
>

... if you already know how to do that. That's the point.

Regards,

_______________________________________________
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 Imants Cekusins
On 10/02/2015 11:38 PM, Imants Cekusins wrote:

> speaking not about this particular "return" issue but change as such:
>
> change can be
> a) avoided or
> b) accommodated.
>
> let's think of abstract languages L and N. Any resemblance is
> coincidental and irrelevant.
>
>
(snip)

I'm sorry, but you're going to have to put that in "working
programmer" terms, at least if I'm ever going to understand it.

Like most working programmers, I personally don't thrive on formal
semantics/methods (though I do often benefit from them, even unknowingly!).

Can you explain the problem in layman's terms?

Regards,

_______________________________________________
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
> Can you explain

that paragraph was not a problem but analogy. Here is a pared down version :

if given choice,  what would you and beginners prefer :  libraries (no
change, libraries work) or better syntax (change, libraries break)?

please do not apply this to this particular issue ("return"). Which
syntax is better, whether libraries break, is a different question.
_______________________________________________
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`

Evan Laforge
In reply to this post by Mario Blažević
On Fri, Oct 2, 2015 at 2:55 PM, Mario Blažević <[hidden email]> wrote:
>> "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.
>
>         Naming of applicative sub-expressions is perfectly doable without
> reaching for any syntactic sugar. An applicative do like

Isn't the debate about 'return', not about ApplicativeDo?
ApplicativeDo is already in the next version, so I think it's been
decided.
_______________________________________________
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:

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