Ah, if only some one had implemented one.
I guess there is no reason NOT to implement this? It's still only a
single class, and single object per function? The class is going to be
longer, because method bodies like...
public Object invoke(Object arg1, Object arg2) {
return throwArity(2);
}
will get overridden with implementation, so I guess it *might* slow
start up time, and an AOT jar will get bigger.
So, the question is, did it just get forgotten or is it harder than it
looks?
Phil
Andy Fingerhut <andy.finger...@gmail.com> writes:
> http://dev.clojure.org/jira/browse/CLJ-731 ?
>
> On Tue, Oct 28, 2014 at 2:39 AM, Phillip Lord <phillip.l...@newcastle.ac.uk>
> wrote:
>
>> Reid McKenzie <rmckenzi...@gmail.com> writes:
>> > This suggests that |apply| is immensely expensive in general,
>> > and that such arity unrolling even for trivial functions would be a good
>> > thing. Albeit hard to build.
>>
>>
>> Wonder whether it is macroable. Something like
>>
>>
>> (def new-function
>> (with-arities [20]
>> [args]
>> (blah args)
>> [args & rest]
>> (apply args rest)))
>>
>>
>> which gets replaced with
>>
>> (fn
>> ([]
>> (blah))
>> ([a]
>> (blah a))
>> ;;...etc
>> ([a...t]
>> (blah a...t))
>> ([a...t & rest]
>> (apply blah a...t rest)))
>>
>>
>> Where a...t are the symbols a to t. Would this help? The function blah,
>> of course, would know what it's arity is, but this is true for most
>> higher-order functions (if functions returned their arities, I guess you
>> could work around this, but they don't).
>>
>> So, partial would become something like...
>>
>> (def partial
>> (with-arities [:all]
>> [args]
>> (fn [args] (args))
>> [args & rest]
>> (fn [& rst] (apply (list* args rst)))))
>>
>>
>> Just thinking aloud!
>>
>> Phil
>>
>> --
>> 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
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
