Thanks for your thoughtful reply, see below.
On Mar 13, 2010, at 3:03 AM, Konrad Hinsen wrote:
> On 13 Mar 2010, at 03:32, Jonathan Shore wrote:
>
>> Could + and other operators be changed to a macro mapping rather than the
>> current defn, mapping the argument list to a binary expression tree (+ (+
>> (+ ... instead of the list style application (I'm guessing yes, not being
>> familiar with CL-style macros).
>
> This would not be a good idea for the arithmetic functions in clojure.core,
> as macros come with their own restrictions. For example, if + were a macro,
> you couldn't pass it as an argument to map, reduce, or apply. All of these
> occur very frequently.
ic your point. Then really what I am asking for is for the compiler to
decompose these into binary operations in a future release.
>
> I don't really share your worries at this time because the kind of
> performance problem you describe can always be fixed in a later optimized
> implementation.
Perhaps not, but most of my work would have to be done in Java, which for me
would be unacceptabe. I'm thinking Clojure is premature for my work at the
moment.
> Clojure is still a very young and evolving language, so that level of
> optimization cannot be expected in my opinion.
I recognize that Clojure is a smaller effort. It may well be that users in
the clojure community use clojure in situations that are not as performance
sensitive. For possible adopters with issues such as mine, clojure
competitors are much ahead on the performance angle. I do hope that the
compiler rewrite is to put focus on perf.
>
> Yes, a macro has access to everything. It is perfectly possible, and even not
> very difficult, to write a macro that does the transformation you describe.
> The tricky part is knowing when it is a good idea to apply it - but if you
> leave that decision to the programmer using it, the problem becomes a quite
> straightforward one to solve.
>
>> Automatically decorating literals that are used in the context of arithmetic
>> with a primitive would make clojure a lot more usable for
>> performance-concerned arithmetic.
>
> Perhaps. I find it very hard to predict what can be gained by a specific
> optimization, since it's so hard to predict what the JIT compiler will take
> care of automatically.
I could be wrong, but would think that:
static public int intCast(Object x){
if(x instanceof Number)
return ((Number) x).intValue();
return ((Character) x).charValue();
}
the "if" statement is not going to be optimised away by JIT. (This is what
gets called on the literals).
>
>> I think I saw mention that #^int (and other primitive types) will be
>> supported at some point in argument declarations as well?
>
> That has been mentioned on this list, but I don't expect it to happen before
> the rewrite of the Clojure compiler in Clojure itself.
>
> Konrad.
>
>
--
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
