Javascript bytecode

[Max Samukha]

On Wednesday, 19 December 2012 at 08:45:20 UTC, Walter Bright 
wrote:
> On 12/19/2012 12:19 AM, Max Samukha wrote:
>>> Evidently you've dismissed all of my posts in this thread on 
>>> that topic :-)
>> As you dismissed all points in favor of bytecode.
>
> And I gave detailed reasons why.
>
>> Such as it being a
>> standardized AST representation for multiple languages. CLI is 
>> all about that,
>> which is reflected in its name. LLVM is used almost 
>> exclusively for that purpose
>> (clang is great).
>
> My arguments were all based on the idea of distributing 
> "compiled" source code in bytecode format.
>
> The idea of using some common intermediate format to tie 
> together multiple front ends and multiple back ends is 
> something completely different.
>
> And, surprise (!), I've done that, too. The original C compiler 
> I wrote for many years was a multipass affair, that 
> communicated the data from one pass to the next via an 
> intermediate file. I was forced into such a system because DOS 
> just didn't have enough memory to combine the passes.
>
> I dumped it when more memory became available, as it was the 
> source of major slowdowns in the compilation process.
>
> Note that such a system need not be *bytecode* at all, it can 
> just hand the data structure off from one pass to the next. In 
> fact, an actual bytecode requires a serialization of the data 
> structures and then a reconstruction of them - rather pointless.
>

I understand that but can not fully agree. The problem is the 
components of such a system are distributed and not 
binary-compatible. The data structures are intended to be 
transferred over a stream and you *have* to serialize at one end 
and deserialize at the the other.

For example, we serialize a D host app and a C library into 
portable pnacl bitcode and transfer it to Chrome for compilation 
and execution. There is no point in having C, D (or whatever 
other languages people are going to invent) front-ends on the 
receiving side. The same applies to JS - people "serialize" ASTs 
generated from, say, a CoffeeScript source into JS, transfer that 
to the browser, which "deserializes" JS into an internal AST 
representation.

Note that I am not arguing that bytecode is the best kind of 
standard AST representation. I am arguing that there *is* a point 
in such serialized representation. Hence, your claim that ILs are 
*completely* useless is not quite convincing.

When we have a single God language (I wouldn't object if it were 
D but it is not yet ;)), then there would be no need in 
complications like ILs.

>
>> Not advocating bytecode here but you claiming it is completely 
>> useless is so
>> D-ish :).
>
> I'm not without experience doing everything bytecode is 
> allegedly good at.

I am not doubting your experience but that might be an 
authoritative argument.

>
> As for CLI, it is great for implementing C#. For other 
> languages, not so much. There turned out to be no way to 
> efficiently represent D slices in it, for example.

That is the limitation of CLI, not the concept. LLVM does not 
have that problem.