Al,

> Perhaps the basic problem here is just that "lambda" is cognitively a
> single letter, but it requires six letters to spell in english. If
> you write:
>  
>   (define-syntax l (syntax-rules () ((l . foo) (lambda . foo))))
>
> then you have a compact and powerful notation for "curry"-ing:

You are perfectly right! It occurred to me many years ago that
millions of keyboards (those which got a stroke of LISP) would
show different signs of wear if the $\lambda$-calculus had been
named $f$-calculus or "->"-calculus instead. But I am not too
unhappy with lambda. (Imagine, for example, the untolerable loss
of students who did not get attracted to your programming language
courses because they miss the mystical glow of the greek lowercase.
All these souls would end up in courses with the gleamy JOIN
symbol of relational algebra...) But I am quite happy with lambda.

In any case, I presume you do not advocate the replacement of
'lambda' by 'l' but rather ask what the "curry without currying"
mechanism is worth in practice with respect to data compression
of the keystroke stream. Here is a possible answer:

If you leave the realm of simple examples like

>   (curry + 2 <>)           <=>    (l (x) (+ 2 x))
>   (curry list 1 <> 2 <>)   <=>    (l (x y) (list 1 x 2 y))

you can find examples where it is an advantage to drop the
actual names of the variables, especially if they are longer.
The break even point comes when

   Sum(n[i] : i in {1..r}) >= r,

where n[i] is the number of characters in the name of the
i-th parameter of the result, for i in {1..r}. In other
words, the 'curry'-notation is shorter when there is at
least one variable name with more than one character.
For example,

     (curry cons-stream <> stream)
<=>  (l (object stream) (cons-stream object stream))

(Did I tell you that I work on combinatorial optimization? ;-)

But seriously, the intended benefit of the SRFI is to
make a certain class of lambda-expressions explicit;
the notation aspect is just an aside.

Sebastian.