On Jun 17, 2010, at 11:57 PM, Mark Engelberg wrote:
Thanks for the responses.
Going back to the naive factorial function:
(defn fact [n]
(if (zero? n) 1 (* n (fact (dec n)))))
Right now,
user=> (fact 40)
815915283247897734345611269596115894272000000000
Under the proposed changes,
user=> (fact 40)
java.lang.ArithmeticException: integer overflow
So the same code now risks an arithmetic exception. What have I, the
programmer, gained from this new level of risk? The answer, if I'm
the kind of programmer who has no interest in putting in type
annotations into the header of the function, is nothing. There is no
speed improvement without the additional type annotations. So all
I've gained is the /potential/ for a speed improvement.
I fully acknowledge this is a breaking change that doesn't suit your
preferences. But again, you are over- and misstating things.
The benefit does not only accrue to those annotating their arguments.
Because many functions and methods return primitives (and more will,
now that fns can return primitives), any operations on their results
and/or literals can be optimized. E.g. things like (if (< (dec (count
x)) 100) ...) can now be optimized into primitives.
I assume that most Clojure users really like its dynamic nature. If
this is true, then for most of us, the common case is to NOT annotate
our code with types. Certainly I like the idea of making it as easy
as possible to write fast code in Clojure. I want my dynamically
typed code to be as fast as it can be, and it's nice to know that
there is a way to write statically typed code that is even faster.
But I really don't want to incur a penalty (i.e., possibility of
Arithmetic Exception) when I'm not using type annotations.
I agree that the burden on those who want to write type annotated code
is too high. I agree that this should be made easier. But
ultimately, I still want the burden to be on them (or me, the 1% time
I need it), not those of us who prefer unannotated code. I that some
of the changes you have proposed for moving the annotations into the
header, along with literal notation for long (i.e., 0L rather than
(long 0)) would be preferable to the bigint dichotomy.
I agree that an improved bigint type would address the performance
aspect of my argument. On the other hand, it wouldn't really address
the problem of using these things in sets and hash tables. I think
it's very important that Clojure have one unique canonical
representation for numbers arrived at through Clojure-based
computations. It is very difficult to use numbers sanely if that's
not the case.
Agreed that this equality bit is a separate issue.
Rich
--
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
