Proposal: Applicative => Monad: Call for consensus

[Conal Elliott]

I'm delighted to see the possibility of adding join as a Monad method. I
almost always have an easier time thinking about join than (>>=) and wish I
could define join instead of (>>=), without having to pay the cost of
defining an additional joinFoo function and then having the actual join
function end up implemented via (>>=) via joinFoo.

I relate to Gábor's points that

* The familiarity advantage of (>>=) is a historical accident. I like to see
the language improve over time, rather than accumulate accidents.
* I prefer functions & methods with simpler interfaces over more complex
interfaces. I'm happy to compose these simpler operations to get more
complex operations, e.g. join+fmap vs (>>=).

  - Conal

2011/1/6 Gábor Lehel <illissius at gmail.com>

> On Thu, Jan 6, 2011 at 5:42 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
> > Hi,
> >
> > On Wed, Jan 5, 2011 at 3:29 PM, <roconnor at theorem.ca> wrote:
> >>
> >> On Wed, 5 Jan 2011, Iavor Diatchki wrote:
> >>
> >>> Hi,
> >>>
> >>> On Wed, Jan 5, 2011 at 8:04 AM, <roconnor at theorem.ca> wrote:
> >>>      On Tue, 4 Jan 2011, Iavor Diatchki wrote:
> >>>      In my completion monad, "join" is more efficent than "bind id"
> >>>
> >>>
> >>> This suggests that your monad will work less efficiently if you use it
> >>> with the do-notation.
> >>
> >> No.  If I need to use fmap, there is no getting around it.  Only if I
> use
> >> "bind id" is it faster to use "join".
> >
> > I am not familiar with your monad but if you are not making essential use
> of
> > "bind" (or join and fmap together), then perhaps the monadic structure is
> > not particularly important?
> >
> >>>
> >>> Join and bind are very similar and, at least in standard Haskell code,
> I
> >>> think that "bind" has proven to be a lot
> >>> more useful then "join".
> >>
> >> AFAIU, In applicative style programming "join" has proven to be a lot
> more
> >> useful than "bind".
> >
> > I am not sure what you mean here, I find the "do" notation quite useful.
> >
> >>>
> >>> Also, as I mentioned before, if people find "join" easier to define
> then
> >>> "bind", then they can define "join", and
> >>> then define "bind" in terms of that---I am still not convinced that we
> >>> need a new method added to the Monad class.
> >>
> >> If people find "bind" easier to define "join", then they can define
> >> "bind", and then define "join" in terms of that---Your argument is
> totally
> >> symetric in the terms "bind" and "join".
> >
> > The situation is not symmetric because we already have a class with ">>="
> > and lots of code which depends on it---so I don't think that replacing
> ">>="
> > with "join" is really plausible (I would certainly not support such a
> > change).  I am not convinced that adding "join" to the class, in addition
> to
> > ">>=", buys us anything but complexity.
> > -Iavor
>
> I'm not sure what you mean here by "replace" -- to _remove_ bind from
> Monad, and add join instead? I don't know of anyone proposing this.
>
> You're perfectly correct that it's possible to define a standalone
> join function yourself, and then write in what would be the proposed
> default definition for bind manually -- but roconnor is also perfectly
> correct that if the situation were the other way around, the same
> thing would be true in reverse. In other words, the argument is that
> the situation with bind being a method of Monad and join not being
> such is a historical accident, and not one supported by the merits.
>
> The fact that you can still write the function outside the class and
> define the class method in terms of it manually is true of
> approximately every class method and standalone function ever written.
> We could write all of our classes so that the most complicated and
> impressive functions are the methods, while defining the simple ones
> standalone in terms of those, with perhaps only a small amount of
> annoyance overhead resulting for our users -- but we don't. We tend to
> seek the ability to write minimal class definitions using the simplest
> and most straightforward methods we can find. It sends a message: this
> is the easiest/best way to write an instance. If you resort to writing
> what should've been a method as a standalone function instead and
> defining the method in terms of it, the message it sends is "the
> definition of this class is flawed and I'm working around it". But
> most people probably don't think of doing this, and just define the
> simplest out of whatever methods they are given. After all, writing
> simple functions and then defining the more complex ones as
> combinations of those is what Haskell is all about, isn't it? So we
> should strive to support that, even if it can be done in our spite
> when we don't.
>
> And as has been argued at length in this thread, for a great many
> types it is easier, cognitively if not physically, to define fmap and
> join than to define bind. (And for the others, like Oleg's example,
> they can just say fmap = liftM and keep merrily on.) It was actually
> thinking about the type signature of join which made the whole Monad
> thing finally 'click' for me, which isn't bad considering that
> Applicative has only about halfway clicked so far. It absolutely feels
> more fundamental as an operation than bind does, even if bind might be
> the more useful combinator.
>
> There's also the consideration that when defining instances for a new
> type, many (most?) people tend to write an instance for the superest
> class in a hierarchy first, and then to work their way down. (Even
> without the hierarchy being explicit a lot of people, myself included,
> already do this for Functor/Applicative/Monad). So by the time they
> get to Monad they have an fmap already written, and they're like --
> "why do I have to reimplement essentially the same functionality again
> as part of (>>=)? Oh wait, here's join instead, that'll be easier."
>
>
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> >
>
>
>
> --
> Work is punishment for failing to procrastinate effectively.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110109/2b461ffc/attachment-0001.htm>