[plt-scheme] Why do layman programmers care about Currying?

From: Joe Marshall (jmarshall at alum.mit.edu)
Date: Tue Jan 6 17:03:23 EST 2009

On Sat, Jan 3, 2009 at 9:30 PM, John Clements <clements at brinckerhoff.org> wrote:
> I think you've misunderstood monads: see my comments below.

I don't *think* so, but I did gloss over some stuff.

> What you're saying makes some sense, but I don't think you'd describe this
> programming pattern as being a monadic one.
> As a matter of fact, using e.g. the store monad in Haskell *does* require
> quite an elaborate rewrite, typically using 'do' & 'return' in every
> function to be transformed.

Er, well, you caught me out.  I was thinking of the maybe monad when I started
the paragraph, but when I got to the end I decided I'd refer to the state monad
instead and simply changed a few words.  It is true that if you wish
to refer to the
state (or whatever it is you factored out of the code) that you have
to use a `do'
`return' pair, and the whole point of a state monad is so each
function can `modify'
the state, thus nearly every function needs to be modified.

> There *is* one way in which Haskell's 'do' is much nicer than this one:
> Haskell's type system makes it possible to define a 'do' that works for a
> whole bunch of different monads, and isn't chained to just one. In Scheme,
> if you want to use 'do' for different monads, you'll probably have to enrich
> uses of 'do' to indicate which monad's 'bind' to expand into.

I think this is a seductively bad idea.  Yeah, it's nice that the type
system figures
out what to dispatch to, but dispatching on the return type is heinous.  (It
introduces context sensitivity.)

>> That's why I said that the Haskell community would be far less
>> excited about monads if their language didn't automagically do the
>> currying.
> By the above, I believe this is incorrect.  I would instead suggest that the
> Haskell community would be far less excited about monads if their language
> provided mutation.

True, but it's hardly as amusing.  But I think it is the confluence of
a few things
that make monads attractive to Haskellers.  There is the strong motivation to
find *some* mechanism to write serial code without breaking the entire world,
but there are alternatives to monads.  The other contributing factors are
the ability to automatically dispatch on the return type, the ease of currying,
and the nastiness of continuation-passing-style in fully typed languages.

Incidentally, I observed someone writing code with the state monad the
other day.
He didn't actually need to model state, he just wanted to program in
`imperative style'
(smash this `register', assign this to that, for i from 1 to 10, etc.)
and the monad was there
just to let him use the `do' syntax.  Yuck!


Posted on the users mailing list.