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