On Wednesday, 10 December 2014 at 22:34:50 UTC, Dicebot wrote:
Then please show something that actually helps and is
applicable to D template system. There is not much value in
vague references with "imagine rest yourself" flavor.
To be specific I am interested how would it handle pattern like
this (very common for D code and not present in Ada at all
AFAIK):
void foo(T)(T t)
{
mixin(generator!T());
}
What exactly would one put in IR for plain uninstantiated foo?
Maybe you should agree on what a high level IR is first? Here are
some alternatives:
1. Regular IR: A high level IR basically is a flattened AST where
you do substitutions, perform partial evaluation and strip out
symbols. In a high level IR that supports templating you might
preserve several partial instances using incomplete types. If it
is non-transformable to begin with… then the compiler won't
transform it.
2. Search optimizing IR: What the compiler does could be based on
heuristics and statistical information. Think term rewriting
systems working on "possible programs" with heuristics as a guide
so you build up a database of precompiled segments for "possible
programs" and produce guiding datastructures that speed the
optimization search. The basic idea being that you spend a lot of
time precompiling libraries, and cut down on compiling concrete
instances of programs.
3. Generating IR: The compiler could build JITable compiler code
for templates, e.g. the templates are stored as a VM program that
is executed by the compiler and is allowed to make calls into the
compiler code. Basically "compile-time-functions" with inside
compiler know-how.
