Would it help to have a naming convention for Clojure to distinguish compile-time flags from normal dynamic vars? // ben
On Tue, Dec 6, 2011 at 17:05, David Nolen <dnolen.li...@gmail.com> wrote: > *unchecked-math* is a compiler flag. > > On Tue, Dec 6, 2011 at 7:00 AM, Cedric Greevey <cgree...@gmail.com> wrote: >> >> user=> (binding [*unchecked-math* true] (map int [33 77 0xffffffff])) >> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out >> of range for int: 4294967295> >> >> The cause of this: >> >> (defn int >> "Coerce to int" >> { >> :inline (fn [x] `(. clojure.lang.RT (~(if *unchecked-math* >> 'uncheckedIntCast 'intCast) ~x))) >> :added "1.0"} >> [x] (. clojure.lang.RT (intCast x))) >> >> The inline and non-inline version don't coincide -- the non-inline version >> lacks the check for *unchecked-math*. >> >> On top of that, the inline version sort-of doesn't work anyway -- >> specifically, it doesn't work if you do "the obvious": >> >> user=> (binding [*unchecked-math* true] (int 0xffffffff)) >> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out >> of range for int: 4294967295> >> user=> (defn foo [] (binding [*unchecked-math* true] (int 0xffffffff))) >> #'user/foo >> user=> (foo) >> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out >> of range for int: 4294967295> >> >> The problem there is apparently that it checks *unchecked-math* at >> macroexpansion time, and of course binding it at runtime to do some >> unchecked math therefore binds it too late to influence the int function. >> >> If this is intentional, to avoid expensive runtime checks of dynamic Vars, >> then there are two additional problems. >> >> First, there's the apparent lack of an unchecked-int function, or similar, >> that either is unchecked or checks *unchecked-math* at runtime, for those >> who want dynamic behavior even if there's a cost. >> >> Without this, there's no way to get unchecked int casts in map and other >> HOFs short of ugly hacks like #(int %) or #(clojure.lang.RT/uncheckedIntCast >> %). >> >> Another use case would be when using ints not for speed but because you >> want a 32-bit wraparound integer for some other purpose, such as talking to >> I/O devices or legacy file formats that want such things, or to implement >> certain algorithms that rely heavily on wraparound and bit arithmetic in a >> relatively speed-insensitive context, likely where I/O is the bottleneck. >> >> Furthermore, though (do (set! *unchecked-math* true) (println (int >> 0xffffffff)) (set! *unchecked-math* false)) works, it is ugly as sin and >> set! is (usually) evil. >> >> -- >> 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 > > > -- > 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 -- 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