Package smacs.write

[7] Java Code Generation and Formatting The actual code generation has three basic parts.

See:
Description

Class Summary

ExportJavaScripts	handle java script generation.
ExportModule	frontend handler node.
ExportProgramList	take optimized highlevel rule information and store them for script compilation.
ExportPsqlScripts	handle pl/sql script generation.
ExportScriptNode	base node for smacs.write namespace.

Package smacs.write Description

[7] Java Code Generation and Formatting

The actual code generation has three basic parts.

expand representation

The internal smacs representation contains mostly descriptive node types. These need to be expanded into multiple nodes that represent executable node types. The expansion is really local where there are often three parts - a list of needed prerequisits that should be initialized before, a list of the actual invokations based on the prerequisits and its subtree nodes, and a list of required cleanup executions.

commonize generations

The expansions have left a lot of program-oriented declarations definining prequisits. These are usually things like "I need a loop variable here of type int". Program-oriented. But there might be more complex initializations to it, like loading a module (oracle driver) and connection setup.

The commonize step will walk a series of trees and assemble the needed requisites. It will also attempt basic lifetime analysis so we have only one instance of an "int loop variable" if the actual usages are in strictly different phases. The commonizing result is the generation of new nodes in places higher-up in the tree - specifying constructions and deconstructions around a subtree of executions.

For the actual smacs case, do not forget to express the loading of any modules needed to call a user-defined function in a later place.

formatting

The formatting has again a set of subrequirements that are largely targetted to please the human eye in the output program text. For a computer alone it would be suffiction to process the programmtext tree, generate all new names with x&; number&;, and possibly put each function on one line (or each symbol on a new line).

Instead we want to have (a) proper indention of program text following blocklevels (b) break long lines into multiple ones and adjust indention for the continuation (c) choose descriptive names for functions and local variables (d) add comment text telling the user any names that were used to generate a specific construct.

And finally, we need to add any glue code into places were the user requested a special subtype of a possible target. This may be things like logging routines, or the generation as a jar application, an applet, a thread bean. The packaging is an important step of generation, including variants of expressing module dependencies.