[Haskell-cafe] Martin Odersky on "What's wrong with Monads"

[wren ng thornton]

On 6/24/12 5:41 AM, Anton Kholomiov wrote:
> I think monad's methods are misleading, let's rename them
>
> class Monad m where
>      idM  :: a ->  m a
>      (*$) :: (a ->  m b) ->  m a ->  m b
>
> We can see that `return` is a monadic identity and the `bind`
> is an application in disguise. So now we have two applications.
> It's standard `($)` and monadic `(*$)`. But they are application.
> Well isn't it something like `plusInt` and `plusDouble`?
> Maybe we can devise single class for application. Let's
> imagine a special class `App`
>
> class App ?? where
>      ($) :: ???
>
> As you can see it's defined so that we can fit
> monads and plain functions in this framework. Moreover
> if we redefine this class than whitespace is redefined
> automatically!

The class you're looking for is Applicative. The (<*>) operator handles 
application of "effectful" things to "effectful" things, whereas (<$>) 
handles the application of non-"effectful" things to "effectful" things. 
This situation is interesting because it highlights the fact that there 
is a distinction between the meaning of whitespace between function and 
argument vs the meaning of whitespace between argument and argument.

The desire to invoke (<$>) and (<*>) implicitly is known as idiom 
brackets. SHE provides this as syntactic sugar, and of course you can 
define your own version using iI and Ii as your "brackets".


> So `($)` really means *white space* in haskell.

Not entirely so, as noted above. Though yes, ($) denotes application in 
just the same way as function--argument whitespace does. However, the 
presence of ($) as an operator is helpful because it allows us to 
capture the syntax of our language, as in:

     fmap ($x) fs

     zipWith ($) fs xs

     ...

-- 
Live well,
~wren