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.
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.
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.
There other part of an intermediate representation which you
ignored is attaching *multiple backends* which is important for
portability and the web.
Applications could be written in safeD (a subset that is supposed
to have no implementation defined or undefined behaviors) and
compiled to such an intermediate representation (let's call it
common-IR since you don't like "bytecode"). Now, each client
platform has its own backend for our common-IR. We can have
install-time compilation like in .NET or JIT as in Java or both,
or maybe some other such method.
Having such format allows to add distribution to the system. The
serialization and de-serialization is only pointless when done on
the same machine.
Another usecase could be a compilation server - we can put only
the front-end on client machines and do the optimizations and
native code generation on the server. This can be used for
example in a browser to allow D scripting. Think for instant
about smart-phone browsers.
the dreaded "bytecode" helps to solve all those use cases.
