D front-end in D for D

[David Piepgrass]

On Saturday, 14 July 2012 at 10:48:56 UTC, Gor Gyolchanyan wrote:
> I just got an amazing thought. If we end up getting a D 
> front-end in D, I
> think it would be possible to make the back-end in the same 
> space as the
> code being compiled. This means, having the back-end as a 
> library solution.
> This would automatically provide 100% compile-time code 
> introspection. This
> is just a thought. Not a proposal or anything. What do you guys 
> think?

Compile-time code introspection is a job for the front-end. It's 
not very good to have code introspect itself at compile-time 
using a library... that would mean the library loads, parses and 
analyzes the very same code that the compiler has already loaded, 
parsed and analyzed. Sounds quite inefficient, and is it even 
legal to read files at compile time, and how would you know what 
paths to read?

Having the front+back-end as a library would, of course, be handy 
for run-time code generation, which definitely is useful place 
too. In C# there's a handy library called RunSharp for that, and 
I miss it in C++. It would, however, mean bundling a complete 
compiler with your application, so the solution feels very heavy 
(as compared to the .NET framework, where developers can take for 
granted that the user's machine already has the libraries.)

I think, for multiple reasons including this use case, D should 
have a "lightweight subset" with a smaller standard library and a 
somewhat simpler language definition (that retains most of D's 
power), which could shrink the size of a program that uses 
runtime codegen. For simplicity, the D front-end written in D 
could use the same backend for CTFE as for its output. And one 
hopes that generated code could be garbage-collected.

However, presumably you'd have to include LLVM which I believe is 
around 1MB for a bare-minimum build (with no optimization passes 
included.)