|Code Generators email@example.com (Kenn Heinrich) (1991-04-12)|
|Code Generators firstname.lastname@example.org (Mike Lichak) (1998-08-22)|
|Re: Code Generators email@example.com (Chris F Clark) (1998-08-24)|
|Re: Code Generators firstname.lastname@example.org (1998-08-24)|
|Re: Code Generators email@example.com (Joachim Durchholz) (1998-08-25)|
|Re: Code Generators firstname.lastname@example.org (1998-08-25)|
|Re: Code Generators email@example.com (1998-08-25)|
|From:||Chris F Clark <firstname.lastname@example.org>|
|Date:||24 Aug 1998 13:32:50 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
email@example.com wrote a problem with code generators:
> I have written several of these type of code generators the last 15
> years, and they save a lot of time.
> Here's the problems I always run into. The code can be compiled and
> delivered, as is, to the end-user, about 80% of the time. The rest of
> the time, I have to hand-edit parts of the code.
> Once I do that, and find a bug in my code-generator, or add a nifty
> new feature to the code-generator, I have to hand modify or cut and
> pasted that 20% of customized code.
Look up "Generation Gap" in Vlissides latest book:
_Pattern_Hatching_Design_Patterns_Applied_ (ISBN 0-201-43293-5).
The basic idea is to find a way to separate the part you hand mangle
from the parts you generate. It's easiest to do in an object-oriented
environment, where the underlying tool takes care of it. However, if
you design your generator to provide hooks that you can override, you
can do it anywhere.
To make it particularly pretty, find a way to include the hook
overrides right in your code-generator language. A lot of hooks can
be coded in the generator simply as, if the input specifies a value
for the code to output at x, output the code the input specified,
otherwise output the default code.
For a good example of how to do that, look at your local parser
generator (yacc, for instance). The designer of yacc knew that people
were going to need to customize the activity of the parser at
different points in the parse. Therefore, one can stick C code in
braces in any part of any rule in a grammar and the parser executes
that code when it comes to that part of the parse. The designer of
yacc also knew that users would need to customize the type passed on
the parse stack and put in a union declaration to handle that. Yacc
derivatives have added other things you can customize.
The hard part of this is defining the hooks that can be overridden.
However, if you get to the point where you want to hack, you know what
you want to hack and that guides where you put the hook.
Hope this helps,
Chris Clark Internet : firstname.lastname@example.org
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
Web Site in Progress: Web Site : http://world.std.com/~compres
Return to the
Search the comp.compilers archives again.