Proposal: Applicative => Monad: Call for consensus

[Iavor Diatchki]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110106/2071287b/attachment-0001.htm>