this section summarizes past and existing RTCG practice.

originally RTCG was implemented by writing machine code that produced machine code eg [blit] [synthesis]. this is hard.

the lisp community has long valued RTCG. backquote/comma and syntax-rules make writing code-producing code easier. common lisp's standardized macro and meta-programming features are considered crucial to fully utilizing lisp [onlisp] [abelson]. RTCG is a foreign term, not a foreign concept: the lisper thinks `compiling eval' instead.

the C community's has been slower to address RTCG and meta-programming: the current state-of-the-art is cpp, batch compilation, and lex/yacc, with the occasional sed or awk script for good measure. C libraries for building and compiling Intermediate Representations (IRs, eg graphs, quadruples, RTL, etc) are appearing [pardo] [DCG]. more recent projects augment C with backquote-style syntax for RTCG [`C] [spin/chambers thing]. i would find something like these systems very useful.

analysis: backquote is very general but still confusing. automatic `transformer generators' (eg synax-rules, lex/yacc) are useful, but lack the generality of backquote. how can a transformation system be both general and automatic?

maybe this will work. note that comma/backquote indicate types of computation: early and late (different from value types like int or char*). thus type-checking can be adopted to avoid `obvious' logical problems with backquote code, and type-inference can automate the placement of some commas/backquotes.

these `computation types' (static and dynamic, unquoted and quoted), are known as `binding times'. they are used in `partial evalution', the subject of the next section.