CLJS: Checked Arithmetic?

[David Nolen]

In this branch https://github.com/clojure/clojurescript/compare/master...checked-arithmetic, I've implemented one possible approach to checked arithmetic for ClojureScript. In Clojure this means checking for overflow. In JavaScript a much more common source of error is type coercion from the arithmetic operators as well as the introduction of Infinity and NaN.

These changes would prevent the production of NaN and Infinity at least from within ClojureScript itself. Also operations like:

(+ 1 2 "3")

fail instead of producing

"33"

Of course such changes would impose a performance hit. You can currently toggle the behavior with the following macro:

(set-unchecked-arithmetic! true)

This is useful when writing performance sensitive code.

Feedback, improvements appreciated.

David

[philip k]

I'm not so sure about this, but is it possible to throw an exception
when dividing by zero for example? I don't know if exceptions are the
right way of dealing with this at all, but at least this would be
bringing things more in line with Clojure.

On Jan 27, 10:03 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> In this branchhttps://github.com/clojure/clojurescript/compare/master...checked-ari...,

[David Nolen]

On Fri, Jan 27, 2012 at 5:38 PM, philip k <trevo...@gmail.com> wrote:

I'm not so sure about this, but is it possible to throw an exception
when dividing by zero for example? I don't know if exceptions are the
right way of dealing with this at all, but at least this would be
bringing things more in line with Clojure.

divide by zero (introduces Infinity) and arithmetic on non-numbers (introduces NaN) both throw in the checked-arithmetic branch. I personally think exceptions are the way to deal with this as it pinpoints the source of the error quickly without letting bad arithmetic continue on Infinity and NaN. In my experience it's very tedious to debug.

Open to hearing why you think the JavaScript behavior is a good one! 

David

[Max Penet]

Hello David,
This is interesting!
The JavaScript behavior is definitively not a good one, that said the
only thing that I think could do more harm than good is the fact these
checks are enabled by default. I am not sure the majority of cljs user
will want to take a performance hit (or have to set a flag to disable
it) on this given the fields where it will most likely be used (web
ui, web backends), and it might not be obvious to the newcomer.
I would rather have it disabled by default and have to (set-checked-
arithmetic! true) to enable it. But I could be wrong, and in the end
it is mostly a strategy decision, being convenient vs doing it right
(fixing JS).
Max

On Jan 27, 10:03 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> In this branchhttps://github.com/clojure/clojurescript/compare/master...checked-ari...,

[Max Penet]

Sorry about the horrible formatting, blame google groups interface.


Max

[David Nolen]

On Sat, Jan 28, 2012 at 12:16 PM, Max Penet <zcam...@gmail.com> wrote:

Hello David,
This is interesting!
The JavaScript behavior is definitively not a good one, that said the
only thing that I think could do more harm than good is the fact these
checks are enabled by default. I am not sure the majority of cljs user
will want to take a performance hit (or have to set a flag to disable
it) on this given the fields where it will most likely be used (web
ui, web backends), and it might not be obvious to the newcomer.
I would rather have it disabled by default and have to (set-checked-
arithmetic! true) to enable it. But I could be wrong, and in the end
it is mostly a strategy decision, being convenient vs doing it right
(fixing JS).
Max

Clojure favors performance - but correctness comes first. ClojureScript is already *considerably* slower than hand-written JavaScript - we're using copy-on-write data structures, sane truth testing, protocol dispatch, etc. Yet ClojureScript is pragmatic and provides performance escape hatches via simple access to Object, Array, loop/recur statements that compile down to equivalent JS iteration constructs, etc.

I think ClojureScript's gamble on client side development is a good one. Let's write our software right first but make it easy to apply optimizations later.

In my experience as a client side JS developer, I'd prefer some correctness over performance for most applications. For performance sensitive code (like high performance Canvas animation) ClojureScript should most definitely provide the tools such that we can compete with the equivalent JavaScript - ideally with less code.

David