Introduction of specification modules
To use a specification module, e.g. the
AlgScope module in the
it is instantiated by the line
.specs file. All component specification files of the
module are thus included in the set of specifications. A derivation
can be used to inspect all the instantiated files.
The module instance obtained by the instantiation command above
.lido symbol computations for a symbol named
among other specifications.
The above instantiation command is sufficient if only one instantiation of
AlgScope module is used.
Several instantiations of the same module are distinguished by generic
instance names supplied as arguments of the instantiation
$/Name/AlgScope.gnrc +instance=CtrlVar :inst
In this case another instance of the
AlgScope module is generated
having the instance name
CtrlVar. It may coexist with the
unnamed instance created above. The names of its files and
of specified entities (symbols, attributes, etc.) are
prefixed by the instance identifier, e.g.
Some modules have a second generic parameter
It may specialize the module in a second dimension on instantiation:
AlgScope module provides compuations for
IdUseEnv contexts that represent applied occurrences of identifiers.
In some situations it may be necessary to compute more than one
Key attribute in an
IdUseEnv context (if the identifier is
bound in different name spaces). Hence, the
AlgScope module modifies the names of the
AlgScope module is instantiated by
$/Name/AlgScope.gnrc +instance=CtrlVar +referto=Ctrl :inst
it provides computations for the attribute
among other computations.
Other modules use the
referto parameter for different purposes, e.g.
specifying the element type for a generic stack module.
If any of the two generic parameters
is omitted, as in the first two examples, their value is
assumed to be the empty string.
If a module is instantiated as described its facilities can be used
in certain components of the user's specification:
Symbol computations as those provided by the
are associated to symbols of the user's tree grammar by
SYMBOL UseIdent INHERITS IdUseEnv END;
Note: The symbols provided by modules are
CLASS symbols in the
sense of LIDO, i. e. they may not be used directly as tree grammar
INHERITS constructs like the above are needed
to bind their computations to symbols of user's specification.
This means avoids accidental coincidence between names of tree
grammar symbols and of module roles.
.lido specifications may be neccessary to supply information to
or obtain information from the thus inherited computations.
Modules may also provide C functions (directly or via specifications
for other tools), e.g. functions of the environment module in case of the
AlgScope module. They may be called in computations of the user's
.lido specification, or in user's C modules if the appropriate
header file is included.
The same instantiation mechanism may be applied to include user defined modules:
instantiates the module
ModName of a user library.
Such a module must contain of at least two files , e.g.
/user/Lib/ModName.fw containing the module's specifications
/user/Lib/ModName.gnrc. The latter is an executable
shell script that performs the generic module instantiation.
It should have the following form:
moddir=`expr $0 : '\(.*\)/.*' \| '.'`
$1 -e "s/|NAME|/$2/g
s/|KEY|/$3/g" "$moddir"/ModName.fw > "$2"ModName.fw
The last two lines use
sed to substitute the
parameter for any occurrence of
|NAME| in the file
referto parameter for any occurrence of