Javascript bytecode

[Walter Bright]

On 12/18/2012 12:38 PM, Peter Alexander wrote:
> On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
>> On 12/18/2012 10:29 AM, Peter Alexander wrote:
>>> On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
>>>> Javascript proves that bytecode is not required for "write once, run
>>>> everywhere", which was one of the pitches for bytecode.
>>>>
>>>> What is required for w.o.r.e. is a specification for the source code that
>>>> precludes undefined and implementation defined behavior.
>>>
>>> Yes, bytecode isn't strictly required, but it's certainly desirable. Bytecode is
>>> much easier to interpret, much easier to compile to, and more compact.
>>
>> Bytecode would have added nothing to js but complexity.
>>
>> I think you're seriously overestimating the cost of compilation.
>
> When I say "easier", I'm talking about implementation cost. Consider how easy it
> is to write a conforming Java byte code interpreter compared to a conforming
> Java interpreter/compiler. Parsing and semantic analysis are much easier to get
> wrong than a byte code spec. At the bytecode level, you don't need to worry
> about function overloading, symbol tables, variable scoping, type inference,
> forward references etc. etc.  All those things are intentional complexities
> meant to make life easier for the programmer, not the computer. A bytecode
> doesn't need them.

D is open source. There is little implementation cost to doing a compiler for 
it. It's a solved problem.

A bytecode requires another spec to be written, and if you think it's easy to 
make a conformant Java VM bytecode interpreter, think again :-)


>>> The downside of bytecode is loss of high-level meaning... but that depends on
>>> the bytecode. There's nothing stopping the bytecode from being a serialised AST
>>> (actually, that would be ideal).
>>
>> As I pointed out to Andrei, Java bytecode *is* a serialized AST.
>
> It's not a lossless serialisation -- especially not after optimisation. For
> example, it's non-trivial to reconstruct the AST of a for loop from optimised
> bytecode (or even regular bytecode).

Yes, it is trivial. The only thing that is lost are local variable names and 
comments.