The existing generator parses that
format and applies those commands on it to generate the output. The commands can
vary greatly in their complexity. At one extreme, they can be a simple
parameterization of a mostly ?¬?xed generator, in which case the model output format
must be one which that generator can read. At the other extreme, they will be a full
program to run on the model output format, in which case the external generator will
be a compiler or interpreter that runs that program.
It is also possible to combine both models and commands into the same ?¬?le. Here
the model is represented directly as data structure initializers in the language of the
external generator. At the opposite end of the scale, the situation can also result in
models and commands being in similar formats, for instance if the models are
exported asXML and the commands in the form of an XSLT transformation, itself an
XML ?¬?le.
An interesting variation on generator generators occurs where the second stage of
generation is deferred until the runtime of the end system. As the system is started up,
it generates some parts of itself. Clearly, this requires the use of a language that is
suf?¬?ciently dynamic and has good support for re?¬‚ection. It also brings us neatly to our
next topic: looking at various patterns of code that are often found in generated
solutions.
Pages:
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510