[std.database] at compile time

[foobar]

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. 
> 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.