>> This presupposes that compatibility with the C virus is a desirable >> trait, >> doesn't it?
The ability exists now to interface with C code, so there is currently no barrier to such a "virus". I had previously briefly (incompletely) enumerated technical method for making this binary compatibility optional declaratively and/or dynamically, when needed for the performance or interoperability (i.e. simplicity, clarity) benefit. Point being there need be no forced viral spread of the compatibility where it is not needed or desireable. It should be possible for it be 100% seamless such that the dynamic code that doesn't care, is never aware of the VM's internal representation. In 80/20 terms, I don't see any cost so far. Can anyone enumerate a cost the violates the 80/20 rule? Or are you arguing for 99/1% rule? (i.e. "don't mess with my dynamic performance even if it doesn't matter and kills an 80% performance benefit for the performance critical sections") Please elaborate if that is not the case. I realize that someone can make the argument that halving the speed of dynamic code can make all the dynamic code use 2x more resources. However, profiling generally shows that resources issues are concentrated at bottlenecks. -- Neko : One VM to run them all (http://nekovm.org)
