2. LUGARES DE ENUNCIACIÓN
2.3 Cine como soporte y evocador de memorias de la violencia
of specications with dedicated editors that have been generated with Centaur itself. Moreover, Centaur oers a debugger which can be used for validating dynamic semantics of TYPOL programs. As mentioned above, inter-document consistency constraints between METAL, PPML and TYPOL specications are not validated.
6.6.3 PROGRESS
PROGRESS is a specication language for dening graph grammars. It evolved from the IPSEN [Nag85] project where graph grammars were used for the denition of abstract syntax graph structures [ELS87, ELN+92]. PROGRESS, however, is not explicitly devoted to the
specication of syntax graphs, but is intended as a language for the denition of arbitrary graph classes. In [Sch91a], for instance, it is used for the denition of family chart graphs and recently it has been successfully applied to the denition of a CIM environment. As a general purpose language, it can obviously not provide the specic support for tool specication that SSL, the Centaur languages and also GTSL provide. We shall now discuss the extent to which PROGRESS meets our requirements. The comparison with GTSL will highlight the benets of dening a domain specic language for tool specication. GTSL, however, will almost certainly fail if it is used for specifying problems from other domains.
Abstract Syntax:
A PROGRESS specication consists of the denition of node types, node classes, attributes, edge types, a start node type, path expressions, graph tests, graph rewriting rules and transactions. A node type is dened by declaring a type name and determining at least one super node class. Node classes, in turn, dene common properties that several node types inherit. Node classes can, themselves, inherit from multiple other node classes. Attributes in PROGRESS are used to store lexical values as well as semantic information. Attribute types, however, cannot be dened in PROGRESS. A programming language has tobe used for this purpose. An edge type is dened by determining a name and dening the source and target node classes. PROGRESS is polymorphic. Therefore, edges may start from or lead to nodes whose types have been derived from the respective node class determined in the edge type denition. This corresponds to property polymorphism in GTSL. As an example, consider an excerpt of a PROGRESS specication for the Groupie interface tool depicted in Figure 6.18.
node class GRAPH_NODE end; intrinsic Id: Number := 0; end;
node class IDENTIFIER is a GRAPH_NODE intrinsic Name:STRING:=nil;
end;
node class LIST_HEAD is a GRAPH_NODE end; node class LIST_ELEM is a GRAPH_NODE end; node class MODULE is a GRAPH_NODE end; node class PLACEHOLDER is a GRAPH_NODE end; node class MOD_NAME is a IDENTIFIER end; node class OPERATION is a LIST_ELEM end; node class OP_LIST is a LIST_HEAD end; ...
node type PhModule: PLACEHOLDER,MODULE end;
node type ADTModule: MODULE end;
node type ADOModule: MODULE end;
node type ModName: MOD_NAME end;
node type PhOpList: PLACEHOLDER,OP_LIST end;
node type OpList: OP_LIST end;
node type PhOp: PLACEHOLDER,OPERATION end;
node type Function: OPERATION end;
node type Procedure: OPERATION end;
edge type ToFirst: LIST_HEAD --> LIST_ELEM; edge type ToLast: LIST_HEAD --> LIST_ELEM; edge type ToElem: LIST_HEAD --> LIST_ELEM; edge type ToNext: LIST_ELEM --> LIST_ELEM; ...
Figure 6.18: Abstract Syntax Graph Structure in PROGRESS
The most general node class is GRAPH NODE. Node class IDENTIFIERdenes an attribute Name,
which is used to store the lexical value of the identier. The attribute is declared to be
intrinsic, which means that values will be assigned externally.
PROGRESS does not include any primitives for ordered multi-valued edges that are required in syntax graph denitions and are, therefore, included in SSL, METAL and GTSL. In fact, a number of additional edges are needed to implement these list structures. Inheritance may be used to partly overcome this deciency. The example, therefore, denes two abstract node classesLIST HEADandLIST ELEMfor that purpose. Heads implement a class for the source nodes
of a multi-valued edge and LIST ELEM denes the target class. Four edge types are introduced
for lists, namely ToFirst,ToLast,ToElemandToNext. Edges of the rst two types connect the
head of a list with the rst or last element respectively. ToElemedges connect the head with
each element and ToNextedges connect each element of a list with its successor element.
Node classMODULEdenes the common properties of arbitrary module node types. Therefore,
the class of node type ADTModule and the other kinds of Groupie modules is MODULE. Note
that we also have to dene a node type to model module place holders. This is due to the fact that PROGRESS, as a general purpose language, does not provide implicit mechanisms to handle the concept of place holders since these are rather specic to syntax-directed tools. GTSL denes this concept in the basic predened classIncrementand implements it in implicit
methods. It thus relieves the tool builder from dening a number of additional node types that are required in PROGRESS.
To fully determine the structure of abstract syntax graphs a number of graph rewriting rules have to be dened. The graph class dened by the PROGRESS specication is then the set of those graphs that can be generated from a start node by applying the rewriting rules. An example of a graph rewriting rule is given below. It denes a generic rule that expands a place holder with four children.
::=
end;
production ExpandWithFourChildren<Root:GRAPH_NODE;1st,2nd,3rd,4th:PLACEHOLDER) =
2:PLACEHOLDER 2’:Root To1st
To2nd To3rd To4th 3’:1st 5’:3rd 4’:2nd 6’:4th
The rule may then be applied within a transaction that determines actual parameters of the formal node type parameters. A transaction that invokes the above rewriting rule in order to expand the dierent types of modules is dened below:
transaction ExpandModule(Current:Number; type:String) = ASTIsOfType<MODULE>(Current) &
choose
when valid type '=' "ADTModule" then
ExpandWithFourChildren<ADTModule,ModName,TypeName,OpList,ImportInterface>(); else
when valid type '=' "ADOModule" then
ExpandWithThreeChildren<ADOModule,ModName,OpList,ImportInterface>(); else
when valid type '=' "FModule" then
ExpandWithThreeChildren<FModule,ModName,OpList,ImportInterface>(); else
when valid type '=' "TCModule" then
ExpandWithTwoChildren<TCModule,ModName,TypeNameList>(); end;
The transaction uses the testASTIsOfTypeto check whether the node Current, which is to be
expanded, is aMODULEplace holder node. Tests are similar to left-hand sides of graph rewriting
rules. They return a boolean value that denes whether the test was successful or not. If the selected increment is a place holder of a subtype of MODULE then a case switch selects which
particular rule to apply based on the argument type. Note that this case switch is necessary
because the actual node type parameters of the graph rewriting rules need to be determined. In GTSL this is solved in a more elegant way by the implicit methods expand and scan to
establish an abstract syntax tree and collapse to delete it. The case switch performed in
the transaction above is implicitly performed in GTSL during dynamic binding. An expand
message sent to an increment is dynamically bound to the right expandmethod, which is the
one dened in the class of the increment. Therefore, the test ASTIsOfType is not required in
GTSL, either.
A further weakness arises if we consider the denition of documents. Besides the edge types that represent abstract syntax relationships, we will also have to dene edge types for se- mantic relationships. These might connect nodes from dierent documents. PROGRESS, however, does not separate these edge types. Therefore, we cannot identify documents within a project-wide abstract syntax graph. As discussed in Section 3.1, the denition of documents is of primary importance for version and conguration management purposes. Therefore, the specication has to be extended with additional node and edge declarations that specify doc- uments. This is extensively discussed in [Wes91]. In GTSL this specication overhead is not required because documents are implicitly dened due to the distinction of abstract syntax children and semantic relationships. Documents are then determined by root increments, i.e.
instances of the predened classDocument. All increments that are reachable from a given root
increment via abstract syntax children implicitly belong to the document.