Hi Kirk, On Thu, Apr 2, 2009 at 4:51 PM, kirk <kirk.pepperd...@gmail.com> wrote:
> > I see a lot of strawman arguments for standardization but I don't really > see anything with substance. I'm not against the standardization route > but I'm just not seeing the need to treat this any differently than > say.. a different GC implementation. How about Escape Analysis or the > internals of IBM's equivalent of HotSpot/JIT which is quite different. > What makes tail recursion different? JRockit 1.4 Mission Control seemed > to force JMX into the 1.5. IMHO, if it is going to make a difference, > others will pick it up and then it will be a lot easier to add it into > the JVM specification. If I'm following this thread right, then what is really meant by TCO is not "JVM implementations are allowed to spot that a certain pattern of bytecodes (eg 0xb6 0xXY 0xZW 0xb0) are a tail-call and MAY be optimised by the JITter" but "a certain, not currently permitted, sequence of bytecodes MUST be optimised as a tail-call so as to not grow the stack" The MUST condition allows us to make semantic guarantees about certain recursive cases not blowing up the stack - important for functional languages. As I understand it, it is not currently possible to implement Scheme fully on the JVM, as the Scheme spec requires compilers to make a form of the above MUST guarantee (I am not a Scheme head, so if this is too much of a simplification, someone please put me right). The reason why one implementation can't just unilaterally introduce it is that the pattern does not cuurently constitute valid Java code as per the spec, and the results of that - ie trying to run code compiled with the new bytecode form on a JVM which doesn't support it would not be good. Imagine the situation where code compiled with one vendor's compiler could not be run on another vendor's JVM, despite them both claiming to support the same classfile version. Dialectisation, vendor-specific extensions to core specs and incompatability of binary files, depending on which compiler you used? Not a world I think we'd like... Thanks, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
