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