[lispm]

Using reader macros for syntax is mostly a mistake - with exceptions. The Lisp tradition generally likes to use reader syntax on the level of s-expressions.

If verbose expressions are a problem, normal macros or functions would be sufficient.

    CL-USER 10 > (defmacro rlambda (fn &rest forms)
                  (let ((arg-sym (gensym "ARG-")))
                    `(lambda (,arg-sym)
                       (,fn ,@forms ,arg-sym))))
    RLAMBDA

    CL-USER 11 > (macroexpand-1 `(rlambda + 2))
    (LAMBDA (#:ARG-804) (+ 2 #:ARG-804))
    T

The 'real problem' is that many people have difficulties using and accepting a programmable programming language.

[cronjobber]

Your "solution" is still more boilerplate than content and befuddles people used to lisp by evaluating in the function namespace an argument in non-function position.

Common Lisp simply can't approach the succinctness and elegance of currying without adding some syntax.

Your resistance is puzzling, btw. You're not having difficulties using and accepting a programmable programming language, are you?

[lispm]

> used to lisp by evaluating in the function namespace an argument in non-function position.

True, macros can confuse people not used to the concept.

For example the DEFUN macro: (defun plus (a b) (+ a b))

'plus' is in the function namespace, even though it is in a non-function position.

Strange, isn't it?

> Common Lisp simply can't approach the succinctness and elegance of currying without adding some syntax.

That's true. But it doesn't even try, because the 'succinctness and elegance' of currying without adding some syntax is a non-goal for Common Lisp. Lisp has always preferred one expression for each function call and over the years it added complex argument lists (variable number of arguments, optional arguments, keyword arguments, ...).

Personally I don't miss things like 'automatic' currying, since they are making the code harder to read (-> currying is not explicitly visible in the source code) and debug.