[proaralyst]

Sorry, currying by default. In the ML-inspired languages, unless a function takes a tuple of its arguments it's curried. This doesn't seem to be the case in any of the Lisps I've looked at. You can certainly curry the functions yourself but the language doesn't seem to make that easy.

[cronjobber]

I'd count ubiquitous currying a design mistake in a dynamically typed language. All your "wrong number of arguments" errors get caught late.

(But the real problem with common lisp is that its version of (+ 2) is the ridiculously verbose (LAMBDA (x) (+ 2 x)) — far too many anonymous functions end up with more boilerplate than content. A decent reader macro might go a long way towards curing curry envy. If I remember correctly, it's [+ 2 _] in Paul Graham's Arc, not bad.)

[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.

[davexunit]

In Scheme there is the "cut" macro:

    (cut + 2 <>)

GNU Guile specifically has a curried definition syntax:

    (define ((foo x) y)
      (list x y))

https://www.gnu.org/software/guile/manual/html_node/Curried-...

Or you can bind "lambda" to another, shorter identifier.

But anyway, Lisp's goal isn't to be extremely terse, so it doesn't bother me.

[bluefox]

Lisp is not about microsyntax and code golf. If you worry about the number of characters and that is "the real problem" with Common Lisp, Perl or J may be a better choice for you.

[mtraven]

In Clojure it's #(+ 2 %), pretty compact if cryptic. Actually no reason you couldn't make a reader macro in CL to look similar.

[jdminhbg]

Slightly less cryptic would be (partial + 2).

[topkekz]

Partial application and currying are two different things.

[jdminhbg]

That's correct, I'm just responding to the specific case here.

[PuercoPop]

Someone already has: https://github.com/eschulte/curry-compose-reader-macros