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

On Wed, Dec 31, 2008 at 3:18 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> You could imagine a world that looks like this:
>
> (define (f #:a (a #f) #:b (b #f) #:c (c #f))
>  (cond
>    [(and a b c) (fcore a b c)]
>    [(and a b) (lambda (c) (fcore a b c))]
>    [(and a c) (lambda (b) (fcore a b c))]
>    [(and b c) (lambda (a) (fcore a b c))]
>    [a (lambda (b c) (fcore a b c))]
>    [b (lambda (a c) (fcore a b c))]
>    [c (lambda (a b) (fcore a b c))]))
>
> ((f #:a 0) 1 2)
> ((f #:a 0 #:c 2) 1)
> ..
>
> John Lamping explored this form of abstraction in his dissertation and I
> always thought there was something neat about it.

I played around with this sort of thing years ago, but the thing I didn't
like was that it is really hard to figure out what (f #:a 0) means.
It's a function
of `the rest of the arguments', but you have to know the ultimate function
fcore to figure out what arguments (and it what order) to call it.  This isn't
much of a problem until you start defining higher order functions and then
you get a real mess of keyword soup.  (And you would want some sort of
`subtractive' mechanism to *omit* arguments previously provided.)

On the other hand, you could just write  (lambda (b c) (fcore 0 b c)) where
you want to use such a function and be done with it.  No ambiguity and
it's already in the language.

On a completely different thought:
I expect the Haskell community would be *far* less excited about monads
if their language didn't automatigically do the currying.

-- 
~jrm