Proposal: Applicative => Monad: Call for consensus

[kahl at cas.mcmaster.ca]

On Wed, Jan 05, 2011 at 10:03:51AM -0800, 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.
> 
> 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".
> 
> 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.

However, people who think in terms of join might also have client code
that uses join, perhaps even more than bind.
Such people still want their faster implementations of join,
which they cannot easily get under the name join if join is not a class member.

This is the usual trade-off: Small classes are nice for
machine-asserted coherence (the equation |join = bind id| will hold),
but not good for performance.

Default definitions take a lot of the pain out of large classes:
The naive implementor is allowed to believe it is a small class.
Ord is a good example for such a large class --- they typically will
come with documentation clarifying that
``A minimal implementation would comprise either ... or ...''.

You might point to the alternative to provide a RULE for your private
implementations, but even if that were portable, and guaranteed to
fire, it still would be a much less natural mechanism to bind a
name from the Monad ``theory'' to a custom implementation.

I therefore vote, in general, for ``large'' Haskell type classes in the
sense that what might be considered a derived item is still made a member,
and suggest to not just include default definitions inside the class,
but also export ``default definition constructor functions'' together
with the class.


Wolfram