On Jan 17, 3:24 pm, Brian Goslinga <quickbasicg...@gmail.com> wrote: > On Jan 17, 3:17 pm, Jason Wolfe <ja...@w01fe.com> wrote:> I think you can. > Let me elaborate on my simplistic example. Compile > > the code for a function twice -- once where everything works within > > primitives, and once where everything works with Objects -- and > > concatenate the bytecode together. Start by running the primitive > > version. On overflow, jump into the corresponding spot in the object > > version (after some patching up / boxing) -- rather than throwing an > > exception. If no overflow happens, you run *exactly* the same > > bytecode as the current unprimed ops. (I'm not sure how this would > > interact with JIT compared to exceptions, though). As soon as > > overflow happens, you run code as if all of the operations were > > primed, until function call exit. > > I'm not sure the JVM allows methods to do that; it might be possible > though.
I believe it's possible, as long as the bytecodes are combined into a single method body (due to the local jump restriction). > This doesn't address the issue that a method has to decide up front > whether it is going to return a primitive or an object. I suppose you > could compile two versions of each function, but brings up two issues: > First, there would be massive code bloat, which might hurt the ability > of the code to be JITed well. This is an issue. I believe it might be avoidable with some tricks, but I don't know enough about JVM internals to say for sure. (I can elaborate on ideas if requested). > Second, if a function is hinted to > return a primitive, it would almost certainly be an error to return > something that isn't a primitive. Correct. As I mentioned earlier, if you hint the return as long, we would always return a long (truncating/throwing if necessary). This is only talking about behavior *within* a function; the external interface of the function is not up for interpretation. And, taking a step back, what people seem to be concerned with is "long" semantics being inferred when that's not what they want. If the user explicitly declares the return value to be a long, this concern would no longer apply. -- 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
