Is it possible to follow the Common Lisp convention of proclaim/declaim/declare in order to specify types?
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 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. I see your point that there are a couple of sides to this argument. I hope I can persuade some more people to speak up for my side :)
-- 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