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.
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. Clojure is still a very young and evolving
language, so that level of optimization cannot be expected in my
opinion.
What is nice about Lisp is that everything that Clojure does, you can
do yourself. If you are not happy with how + works, write your own.
You can make it a function that is more efficient in general, or more
efficient just for your use cases, or you can make it a macro. All you
need to change in your code to use your own version is the ns form at
the beginning which specifies which symbols to take from where. For an
example, see
http://code.google.com/p/clj-nstools/source/browse/src/nstools/generic_math.clj
That does exactly the opposite of what you want: it replaces
arithmetic by a generic and thus slower implementation. But the same
approach would work for whatever other implementation you might want.
Of course, if you come up with a clearly improved arithmetic without
restrictions, it would be nice to propose it for inclusion into
Clojure itself.
Secondly, if one has code like:
(let [
x (int a)
y (int b)]
(+ (* x 2) (* y 3) (* x y 5))
(* x 2) -> a function of (int, Object), as the literal 2 is not
assumed to be a primitive type. This instead needs to be mapped to:
(let [
x (int a)
y (int b)]
(+ (+ (* x (int 2)) (* y (int 3)) (* (* x y) (int 5))))
I don't know if type hints can be interrogated or known at the time
of macro evaluation (I'm guessing not), but if so, would like to see
that in such a macro.
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 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
