On Tue, Jul 26, 2011 at 1:50 AM, BGB <[email protected]> wrote: > whether or not compiling to bytecode is itself an actually effective > security measure, it is the commonly expected security measure. >
Is it? I've not heard anyone speak that way in many, many years. I think people are getting used to JavaScript. > > a "compiler" may be expected (as part of "the process") even if it could be > technically more correctly called an archiver or similar (people may not let > go of the established process easily). > We can benefit from 'compilers' even if we distribute source. For example, JavaScript->JavaScript compilers can optimize code, eliminate dead code, provide static warnings, and so on. We should also be able to compile other languages into the distribution language. I don't mind having a compiler be part of 'the process'. The issue regards the distribution language, not how you reach it. That said, it would often be preferable to distribute source, and use a library or module to parse and compile it. This would allow us to change our implementation without redistributing our intention. A language with good support for 'staging' would be nice. > > granted, yes, there are different ways to approach JIT (whether or not to > inline things, blocks vs traces, ...). > Hotspot, too. It is possible to mix interpretation with compilation. > also, depending on language it may matter: > Agreed. We certainly should *design* the distribution language with an eye on distribution, not just pick an arbitrary language. > > but, I guess the question that can be made is whether or not the bytecode > is intended to be a stable distribution format (of the same sort as JBC or > CIL), or intended more as a transient format which may depend somewhat on > the currently running VM (and may change from one version to the next). > We should not tie our users to a particular distribution of the VM. If you distribute bytecode, or any language, it really should be stable, so that other people can compete with the implementation. Regards, David
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
