On 17.10.2011 01:43, foobar wrote:
foobar Wrote:
Don Wrote:
You're assuming that the compiler can run the code it's generating. This
isn't true in general. Suppose you're on x86, compiling for ARM. You
can't run the ARM code from the compiler.
This is quite possible in Nemerle's model of compilation.
This is the same concept as XLST - a macro is a high level transform
from D code to D code.
1. compile the macro ahead of time into a loadable compiler
module/plugin.
the plugin is compiled for the HOST machine (x86) either by a separate
compiler
or by a cross-compiler that can also compile to its HOST target.
YES!!! This is the whole point. That model requires TWO backends. One
for the host, one for the target.
That is, it requires an entire backend PURELY FOR CTFE.
Yes, of course it is POSSIBLE, but it is an incredible burden to place
on a compiler vendor.
How does that differ from the current situation? We already have a separate
implementation of a D interpreter for CTFE.
That's true, but it's quite different from a separate backend.
The CTFE interpreter doesn't have much in common with a backend. It's
more like a glue layer. Most of what's in there at the moment, is doing
marshalling and error checking.
Suppose instead, you made calls into a real backend. You'd still need a
marshalling layer, first to get the syntax trees into native types for
the backend, and secondly to convert the native types back into syntax
trees. The thing is, you can be changing only part of a syntax tree
(just one element of an array, for example) so if you used a native
backend, the majority of the code in the CTFE interpreter would remain.
Yes, there is an actual CTFE backend in there, but it's tiny.
I disagree with the second point as well - Nothing forces the SAME compiler to
contain two separate implementations as is now the case.
In Fact you could compile the macros with a compiler of a different vendor.
After all that's the purpose of an ABI, isn't it?
In fact it makes the burden on the vendor much smaller since you remove the
need for a separate interpreter.
I forgot to mention an additional aspect of this design - it greatly simplifies
the language which also reduces the burden on the compiler vendor.
You no longer need to support static constructs like "static if", CTFE, is(),
pragma, etc. You also gain more capabilities with less effort,
e.g you could connect to a DB at compile time to validate a SQL query or use
regular IO functions from phobos.
Statements of the form "XXX would make the compiler simpler" seem to
come up quite often, and I can't remember a single one which was made
with much knowledge of where the complexities are!
For example, the most complex thing you listed is is(), because
is(typeof()) accepts all kinds of things which normally wouldn't
compile. This has implications for the whole compiler, and no changes in
how CTFE is done would make it any simpler.
> e.g you could connect to a DB at compile time to validate a SQL query
or use regular IO functions from phobos.
You know, I'm ýet to be convinced that that it's really desirable. The
ability to put all your source in a repository and say, "the executable
depends on this and nothing else", is IMHO of enormous value. Once you
allow it to depend on the result of external function calls, it depends
on all kinds of hidden variables, which are ephemeral, and it seems to
me much better to completely separate that "information gathering" step
from the compilation step.
Note that since it's a snapshot, you *don't* have a guarantee that your
SQL query is still valid by the time the code runs.
BTW there's nothing in the present design which prevents CTFE from being
implemented by doing a JIT to native code. I expect most implementations
will go that way, but they'll be motivated by speed.
Also I'm confused by this term "macros" that keeps popping up. I don't
know why it's being used, and I don't know what it means.
