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
