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

On Tue, Jan 6, 2009 at 3:18 PM, John Clements <clements at brinckerhoff.org> wrote:
>>> 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.)
>
> If I understand you correctly, this is a problem with inferred types being
> heinous, right?  If you explicitly specify the return type of any function
> whose type is monadic, then the context sensitivity goes away. If I
> understand you correctly.

What I object to is not being able to understand what the expression
  foo (x)  means without knowing what you intend to do with answer.

>> ...
>> and the nastiness of continuation-passing-style in fully typed languages.
>
> Hang on.  We've got "statically typed" and "strongly typed," and you're
> adding "fully typed" to the pile? Urg...

Sorry.  What I am referring to here is this.  When I write a function FOO
from int -> int, I am saying that the function accepts a continuation that
is expecting an int, but I do not constrain that function in any other way.
But if the language expects me to statically type both the arguments
and return values of any funarg, the when I CPS convert FOO, I get
  foo (x:int, receiver:(int -> a)) -> a

Suddenly there is an `a' here that wasn't here before.  Suppose I write
a parser that has both succeed and fail continuations.  Now the type
signature is getting pretty hairy.  Now suppose I add the Kleene `*'
to my parser as a higher order CPS function.  The type signature is
essentially impenetrable.

>> 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!
>
> Yes, that's gross.  On the other hand, I find that when writing Scheme these
> days, using mutation gives me the willies; it seems less error-prone to use
> a state monad, where I don't have to worry about other bits of the
> computation coming in and messing up the state.  I *think* this logic is
> bogus, but that's how it feels.

I just avoid using state altogether.

-- 
~jrm