This has been discussed before, and the biggest problem is not optional arguments, but variadic functions. (+), (+ 42), (+ 42 10), (+ 42 10 7), etc. are all legal, so (+ x) would just be x. Currying is a very powerful feature without a doubt, but it's not clear that it works very well with variadic functions. Certainly it's might be powerful for functions of a fixed arity, but explicit partial application might make more sense with the Arc system. See also http://arclanguage.org/item?id=2205.
I think variadic functions tend to be library (general) functions, whereas actual applications are often full of fixed arity functions. For instance, I think you will find that news.arc is full of fixed arity functions.
I believe that looking at the arc libraries when judging the value of implicit currying may be misleading, since its greatest value is in code written for a single application...
This is certainly true, at least to an extent, but it makes currying inconsistent, which is irritating. I'm not convinced that [] and par create substantially longer code than implicit partial application, which (as noted) has issues. And the other problem, as was pointed out, is optional parameters; since they are similar to rest parameters, the objection is similar, but the problem is more insidious.
Since the arity information is lost for any complement ~f (for instance, but any general or composed function will do) of a function f:
(def complement (f) (fn args (no (apply f args))))
automatic currying turns all composed functions into second degree citizens, which adds programmer burden to the use of any function, in keeping track of whether it will invoke or return a new function.
Ahhhrg, too bad.
I searched for the topic before posting, but I didn't found anything on it.
Well, better live with [+ x _], I suppose. At least, it is compatible with variadic functions.
You can also have a par function to curry a function:
(def par (f . args)
" Partially apply `f' to `args'; i.e., return a function which, when called,
calls `f' with `args' and the arguments to the new function. "
(fn newargs (apply f (join args newargs))))
so (par + 42) will do what you want. Also, a generalized swap (which I called flip):
(def flip (fun)
" Returns a function which is the same as `fun', but takes its arguments in
the opposite order. "
(fn args (apply fun (rev args))))
This works for n-ary functions, but is still probably most useful for functions of two arguments: (par (flip -) 42).
Didn't think of "par", cool idea. It could even be turned into a macro, like that:
(par foo x) => [foo x] ; Well maybe too much.
About flip, I'd rather rotate the arguments instead of reverse them. That way, you have access to more arguments orders by composing flip. You could also define flip2, flip3... in the library if they're used often.
Don't you mean [foo x] => (par foo x)? []s aren't fundamental, they're sugar.
I'm not sure there is a sensible way to extend flip to functions taking more than two arguments. Reverse is one, rotate is another; you might as well have two functions for that. It seems like six of one, half a dozen of the other to me.
