Products and Parameters Reference
 
Sometimes a common problem can be solved by a collection of specifications
having a particular structure.
These specifications themselves can be generated, given simpler
specifications.
The products and parameters described in this chapter are most often used
in requests that appear in type-specs files.
They result in specifications that are then used to describe the complete
processor.
:consyntax
Requesting :consyntax will result in a type-`con' file
containing the complete concrete syntax. This includes all concrete
syntax rules provided by the user in type-`con' files (translated
into strict BNF form) as well as rules added to the concrete
syntax as a result of the mapping process
(see Mapping of Syntactic Analysis).
:abstree
Requesting :abstree will result in a type-`lido' file
containing the complete abstract tree grammar.
This consists of all rules supplied by the user in
type-lido files, plus any additional rules derived from rules
appearing only in type-con files in the syntax mapping process
(see Mapping of Syntactic Analysis).
:absyntax
Requesting :absyntax will result in a type-lido file
containing the complete abstract syntax.
This derivation differs from the :abstree derivation
(see abstree -- Abstract Tree Grammar) in that rules which can only be derived
for computed subtrees
(see Computed Subtrees of LIDO - Reference Manual)
are not included.
:pgram
The parsing grammar requested by the :pgram derivation is the
input to the parser generator. This includes the integer encodings of the
terminal symbols, any directives supplied by the user to direct
the automatic error correction of the parser, and each of the BNF rules
in the concrete syntax with associated actions. These actions include
actions supplied by the user as well as actions generated to construct
an abstract syntax tree.
Note that the mapping process may cause the injection of certain chain
rules due to BOTTOMUP constraints specified in the attribute
grammar. These injected rules do not appear in the result of the
:consyntax derivation, which makes :pgram the most appropriate
derivation to consult when trying to resolve parsing conflicts which may
have resulted from the injection of these chain rules.
See BOTTOMUP of Syntactic Analysis.
file.gla :kwd
Specifications that force literals whose lexical structure is defined by
file.gla to be handled specially by the generated scanner.
Normally, each literal found in the context-free grammar is recognized
explicitly by the scanner as the specified character sequence.
This is in contrast to identifiers, denotations and comments,
whose lexical structures are defined by regular expressions.
The literals are defined by their appearance in the grammar, and no
type-gla file describes their structure.
The :kwd product is used when literals are representative of the
character strings
that should appear in the program, but not necessarily identical to them.
The classic case in which :kwd would be used (and from which its
name is derived) is the recognition of mixed-case keywords.
A literal 'if' appearing in a Pascal grammar is representative of
the character strings if, If, iF and IF but is
identical to only the first.
Whenever any one of these four character strings appears in a Pascal
program, it should be recognized by the scanner as an instance of the
literal 'if'.
All Pascal keywords behave in this fashion, and each has the form of an
identifier.
Suppose that file pkeys.gla defines the structure of the literals
used in the grammar, and the following line were added to one of the
type-.specs files for a Pascal compiler:
pkeys.gla :kwd
This would prevent the scanner of the generated compiler from recognizing
Pascal keywords explicitly as the character sequences specified
by the literals given in the grammar.
Other literals (such as :=), which did not fit the definition given
by pkeys.gla, would still be recognized by the scanner as the
specified character sequences.
It is important to remember that the type-`gla' file to which the
kwd derivation is applied defines the form of the literals in
the grammar, not in the input text.
file.gnrc :inst
A specification consisting of one or more files is generated from
file.gnrc.
This product is normally used to instantiate the common problem solutions
that have been stored in the library
(see Module Instantiation of Specification Module Library):
$elipkg/Name/AlgScope.gnrc :inst
Here the path `$elipkg/Name' accesses the portion of the library
devoted to problems arising in the context of name analysis
(see Name Analysis Library of Specification Module Library: Name Analysis).
Type-gnrc files can be supplied by a user.
They are simply shell scripts that carry out whatever
actions are needed to instantiate a generic specification.
Thus a user of Eli can construct generic specifications
appropriate to a specific domain
and use them exactly like library specifications.
Scripts appearing as type-gnrc files are invoked
with up to three parameters.
The first parameter is the sed(1) program,
the second parameter is the string specified by +instance,
and the third parameter is the string specified by +referto.
When the script is invoked, its full path name is used.
Therefore the script can determine the directory in which it is stored,
and access specific files in that directory.
Here is an example of a type-gnrc file,
`$elipkg/Name/AlgScope.gnrc':
#!/bin/sh
# Copyright, 1994, AG-Kastens, University Of Paderborn
moddir=`expr $0 : '\(.*\)/.*' \| '.'`
$1 -e "s/|NAME|/$2/g
s/|KEY|/$3/g" "$moddir"/AlgScope.fw > "$2"AlgScope.fw
It first sets moddir to the name of the directory in which it resides,
then uses sed to modify file `AlgScope.fw' in that directory.
The script replaces the string |NAME| with the string specified by the
+instance parameter of the original request.
(If no +instance parameter was supplied, $1 is empty and
every occurrence of the string |NAME| is simply deleted.)
Similarly, it either replaces the string |KEY| with the string
specified by the +referto parameter or deletes it.
Finally, the name of the output file depends on the
+instance parameter of the original request.
The output file will become part of the specification that contained the
:inst request.
+instance='string'
Use string to name the instance generated by the request.
No spaces are allowed within the string, and characters meaningful to
the shell that interprets the associated type-gnrc file may cause
problems.
Not all generic modules allow distinct instances to be created.
See the documentation of each such module for the precise effect of
+instance.
+referto='string'
Use string to relate the current instance of a generic module to some
specific instance of another generic module.
Not all generic modules allow relationships to be specified.
See the documentation of each such module for the precise effect of
+referto.
+select='string'
Use string to parameterize the current instance of a generic module
by a name of an entity.
Not all generic modules allow such information to be specified.
See the documentation of each such module for the precise effect of
+select.`
|
