Proposal: Applicative => Monad: Call for consensus

[John Smith]

Why is this so contentious? The proposal gives default definitions for bind and join in terms of each other; 
implementers can choose which they prefer to define. Am I being naive?

On 06/01/2011 22:11, Antoine Latter wrote:
> Since this seems to be a contentious part of this proposal, can we
> table it and have it in its own proposal?
>
> I think having it on its own would make a lot of since, as this is the
> sort of change that can happen with almost no concern for backwards
> compatibility - we don't need to tie it to the rest of the
> compatibility breaking changes.
>
> Antoine
>
> 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
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries