English
资源说明：1990s Code dump; a Shell and AWK based cookie cutting module maker
NopGen was an exploratory project to consider how factor out the dependencies from among source code modules, to derive common patterns and integrate new modules in terms of existing patterns.
NopGen was a compositional language, mapping data streams into source code.
At the time I was learning a bit of calculus, and it was very exciting to consider the possibilities.
The NopGen markup, using delimited text with attributed blocks, was purely a case of convergent evolution.
I did not know about SGML while implementing NopGen's and XML didn't yet exist even as hype.
The notation was inspired by a need to conserve the source code identity, byte for byte, so that two factorings could be demonstrated to be equivalent.
Then I discovered Charles Goldfarb's SGML Bible, and a more literate colleague mentioned the entire family of LISP languages.
It was deflating to know that others had explored this wheel decades before my clunky, squarish version.
NopGen was a skunkworks project. Implemented in AWK, the tool worked slowly and it was buggy.
The effort to fix it is not at all worth it, given that a multitude of interconnected templating systems and transformational languages have far surpassed its original intent.
It is now trivial to use PHP or XSLT or any of many Ruby DSLs to act as a source code composition engine, and some languages like Ruby have metacoding as a core idiom.
Nopgen got me interested in SGML, then Scheme and DSSSL, XML and XSLT.
NOPGEN
Copyright 1992 by Mitch C. Amiano.
released to the public domain
No claim is made as to the appropriateness of this software to any task.
Use at your own risk.
No warranty is expressed or implied.
Abstract
Dependancies exist throughout typical application software which make
the code inflexible to external and internal changes. For example, most
data intensive applications make use of some form of data dictionary to
maintain data structure information. Yet, in the software editing process
the implimenter may make only cursory manual use of the information. The
software text created has numerous points at which data structure
'meta-data' is hard coded, unfactored, and unidentified. When (not if)
the structure of the data changes, maintainance costs increase because
Nopgen is source code manipulation device which allows dependancy
factoring. It is similar to a lexical analyzer and parser, with both
user specified and predefined patterns and actions. Output is generated
by automating the typical editing process using a predefined template
for intput. A rough template representative of output text is factored
so as to remove dependancies. The dependancies are documented in the
template text as they are removed, and rules are defined and stored
which are later used to recreate documents similar to the original.
Text Generation Model
The text generator works by editing a file containing source text, using
simple user defined patterns and actions. A pattern and action are together
known as a "coupling". The coupling is used to represent a dependancy in the
source text. A file containing coupling definitions, referred to as a
"junction box," is used to provide a single point of change for maintaining
these dependancies.
The source files, called pattern files, provide the baseline text from
which the output is generated. Couplings are included in the pattern
file at points referred to as "fittings." A fitting is a change point
in the pattern file text. Is specifies, through Nopgen statements,
the effect that a dependancy has on the baseline text.
Couplings represent lists, or sets, of items. They are connected to a
pattern file by inserting fittings. The fitting associates a coupling with
unblocked text (a plain macro), or with blocked text (via Nopgen statements).
An unblocked text fitting is made by prefacing and suffixing a coupling name
with the demarcation patterns, or by inserting an EVALUATE statement.
A fitting is made with a BLOCK defined pattern by using the PASTE statement.
When a coupling is accessed, it is evaluated as if it were a readable file
containing multiple space-delineated fields, in multiple newline delineated
rows. A PASTE statement can edit a text pattern in a BLOCK by using the
information supplied by a coupling. The text read from a coupling can
also be evaluated and reevaluated inline using the EVALUATE statement.
This allows the coupling mechanism to be used for pattern file text
inclusion.
Description of the Code Generation Process
To produce output, couplings are joined to the pattern file via fittings.
A coupling is evaluated at code generation time, and results used to control
editing of the pattern file template.
There are three ways in which pattern file text can be processed
when a coupling is evaluated.
The first is simple replacement of a fitting with the value of its coupling.
In this case, text is processed line by line and passed through with one line
of output (usually) per line of input. This type of fitting is essentially
a type of macro expansion.
The second type of processing involves the BLOCK blocks. It
is essentially an automated cut-and-paste process. A BLOCK block
specifies a frame of text which is copied, cut, and pasted once
for each set of fields in the coupling output. All other
fittings within the block are processed, as in the previous case.
BLOCKs may be parameterized so that they become a form of templates.
A block's parameters may be fitted into the text within the block itself.
They will be replaced with fields read from a coupling, which is evaluated
when a PASTE statement is executed.
By default, no text is output for a block until it is PASTEd into the
highest level block, the "fulltext" block. The "fulltext" block represents
the last pass of text generation, after all baseline text has been read in.
Code Generation Details
Demarcation of fittings from pattern text.
The default demarcation pattern is "$-" . This can be changed with the
environmental variables "DEMARCSTART" and "DEMARCEND". The patterns are
set as regular expressions. See the man pages for grep, ed, awk, or sed for
use of regular expressions. Use of constants is recommended, since
matches via complex regular expressions are not easily debugged
by visual analysis; they can lead to unexpected behavior.
Defining couplings.
Couplings are defined within pattern files using the COUPLING statement.
A default coupling definition file is provided, named "junction.box".
Each line in the junction box defines a coupling which will be used
in editing the pattern file for output.
The junction box entries are Nopgen coupling definition statements.
The Nopgen keyword COUPLING precedes the definition. Like a COUPLING
statement in a pattern file, it needs to be prefaced and suffixed
with demarcation patterns. The value assigned to the coupling represents
an executable command line.
As an example, the following defines a coupling named "tables" which
returns all table names in an SQL database:
$-coupling tables="isql - mydb <
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
