On Sun, Jan 16, 2011 at 3:50 PM, Jason Wolfe <ja...@w01fe.com> wrote: > Moreover, we do not need to redefine the class at run-time. A simple > way to do this: when you compile a function with arithmetic > operations, concatenate bytecode for two versions: essentially, one > with the unprimed (exception-throwing) ops and one with the primed > (overflowing) ones. Now, replace the exceptions in the first path > with local jumps into the second path. There are probably ways to get > around generating two copies of the bytecode in advance, and making > such a unilateral shift to inefficient semantics, but I don't know > enough about JVM internals to say for sure.
The problem is that if you have an arbitrary form that can operate entirely in primitives (some loop/recur perhaps) and you allow primitives to magically convert to Objects in that code, then the entire piece of code has to handle both primitives AND Objects and every single sub-form must be capable of handling primitives as input AND Objects as input and returning primitives if possible... You can't have automatic promotion to Object from primitive and expect any reasonable code to be generated that can maintain primitive performance across arbitrary expressions. Either everything can work with Objects - and you lose performance - or everything must be able to work within primitives (and at most throw exceptions) and remain performant. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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
