On Fri, Jul 29, 2011 at 1:52 AM, Meikel Brandmeyer (kotarak) <m...@kotka.de> wrote: > Hi, > > Am Freitag, 29. Juli 2011 01:28:27 UTC+2 schrieb Sean Corfield: >> >> Kinda hard since that expression is not valid in 1.3 anyway: >> >> ArithmeticException integer overflow >> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374) >> >> So that code breaks explicitly in 1.3 and in many ways (format) is >> then the least of your worries... > > I think this is one of the misunderstandings or points of disagreements (or > whatever you want to name it) in this whole discussion: this code is *not* > broken. And the expression is also perfectly valid. The function call just > throws an exception. This can be handled. Or you use *' which won't overflow > but give a BigInt in that case. > > So you are in full control of what your program does. Nothing is broken > here. One just hast to pay the price for special handling. The JVM doesn't > allow fast and non-overflow in the same operation. Clojure chose to go the > fast route with primitive math. And consequently non-overflow became special > handling. So where is the issue?
Er, "fast" would be for primitive integer arithmetic to wrap rather than throw an exception or auto-promote. Both of the latter behaviors require every math op to be accompanied by a test of some sort and a branch (to either the exception-throwing code or the BigInt constructing code). -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
