Proposal: Applicative => Monad: Call for consensus
iavor.diatchki at gmail.com
Thu Jan 6 17:42:09 CET 2011
On Wed, Jan 5, 2011 at 3:29 PM, <roconnor at theorem.ca> wrote:
> On Wed, 5 Jan 2011, Iavor Diatchki wrote:
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries