5 ms·

I'm not sure I understand what you mean when you say there's no currying in common lisp? If you write functions that are curried then you'll have currying. Am I

I'm not sure I understand what you mean when you say there's no currying in common lisp? If you write functions that are curried then you'll have currying. Am I missing something?

proaralyst 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        > 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 10y ago
    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-Definitions.html 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.
  - mtraven 10y ago
    In Clojure it's #(+ 2 %), pretty compact if cryptic. Actually no reason you couldn't make a reader macro in CL to look similar.
    - PuercoPop 10y ago
      Someone already has: https://github.com/eschulte/curry-compose-reader-macros https://github.com/eschulte/curry-compose-reader-macros
    - jdminhbg 10y ago
      Slightly less cryptic would be (partial + 2).
      - topkekz 10y ago
        Partial application and currying are two different things.
        jdminhbg 10y ago
        That's correct, I'm just responding to the specific case here.
  - bluefox 10y ago
    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.
tempodox 10y ago
You could make a macro that does the currying for you. You'd have to apply it explicitly, as opposed to ML, where it happens automatically. If you build the macro well, the generated machine code won't look much different from ML, though.

I'm not sure I understand what you mean when you say there's no currying in common lisp? If you write functions that are curried then you'll have currying. Am I missing something?

proaralyst 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      > 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 10y ago
  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-Definitions.html 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.
- mtraven 10y ago
  In Clojure it's #(+ 2 %), pretty compact if cryptic. Actually no reason you couldn't make a reader macro in CL to look similar.
  - PuercoPop 10y ago
    Someone already has: https://github.com/eschulte/curry-compose-reader-macros https://github.com/eschulte/curry-compose-reader-macros
  - jdminhbg 10y ago
    Slightly less cryptic would be (partial + 2).
    - topkekz 10y ago
      Partial application and currying are two different things.
      - jdminhbg 10y ago
        That's correct, I'm just responding to the specific case here.
- bluefox 10y ago
  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.

tempodox 10y ago

You could make a macro that does the currying for you. You'd have to apply it explicitly, as opposed to ML, where it happens automatically. If you build the macro well, the generated machine code won't look much different from ML, though.