>From a JVM perspective, f(& arglist) is a one arg function. Try defining a fn with more than 20 args and you will get the "can't specify more than 20 arguments...." error. This is the maximum supported by the Clojure runtime for "non-optimized" fns.
One can argue about the argument size limit of optimized fn calls. Maybe 4 is too low. These limitations has David pointed out are indirectly inherited from the JVM architecture. What maximum is reasonable ? A vast discussion subject... There are multiple ways to work around this limit. Destructuring, passing a map, ... All these options are much more easier and accessible than implementing/modifying the numeric optimizations. Luc P > On Thu, Dec 15, 2011 at 6:51 PM, Softaddicts > <lprefonta...@softaddicts.ca> wrote: > > Hi Cedric, > > > > Your statement " A limitation on primitive arguments simply cannot be > > applicable to a function with no primitive arguments" does not stand > > It is true by axiom. Either the limitation is not actually a > limitation "on primitive arguments" but on something broader, or else > it is not applicable. > > Either the code should have compiled, or the error is different from > what the message stated. > > There's no getting around that. > > > There's also a limit on the # of arguments even without the numeric > > optimization stuff. It's not a bug, it's a limitation. > > As I recall, there's no such limit with the use of a rest arg -- even > an infinite seq can be used, as in > > (defn foo [& xs] > (take 10 xs))ly > > (apply foo (iterate inc 1)) > > though it actually passes a seq in using a single argument in the > underlying Java method (and indeed in the function definition xs is a > single seq argument). > > If it doesn't already, it can accomodate arbitrarily-long lists of > formal parameters by quietly boxing the 20th onwards into a seq and > destructuring it on the other side, i.e. (defn foo [a1 a2 ... a20 a21 > a22 ...] (do-stuff a22)) (foo 1 2 ... 20 21 22 ...) can be made to > behave as (defn foo [a1 a2 ... & a20andbeyond] (let [[a20 a21 a22 ...] > a20andbeyond] (do-stuff a22))) (foo 1 2 ... (list 20 21 22 ...)). If > this isn't already supported, the fn macro itself can be modified to > detect that case and expand in exactly such a manner when that occurs. > > As for the wackiness with primitive returns (even without primitive > arguments) my previous post details something that could probably fix > most or all such issues and gotchas, at the expense of making a > single, relatively uncommon use-case, namely > > (let [f (if foo primitive-fn1 primitive-fn2)] > (f primitive-arg)) > > less efficient and requiring recompilation of static-callers of > primitive-returning functions when the latters' signatures (return > type and number and types of arguments) are changed (changing the > types already seems to require this). > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
