LIDO - Reference Manual
Attributes are associated with symbols and with rules.
They are defined and used in rule computations
and in symbol computations.
Each symbol has two disjoint sets of attributes:
attributes that are defined by computations in lower
contexts of the symbol,
and inherited (
INH) attributes that are defined by
computations in upper contexts of the symbol.
Attributes are introduced by their occurrence in computations.
They are not explicitly declared. How types and classes of attributes
are determined is described in Types and Classes of Attributes.
Attribute ::= SymbolRef '.' AttrName
RuleAttr ::= '.' AttrName
SymbolRef ::= SymbName
| SymbName '[' Number ']'
RhsAttrs ::= 'RHS' '.' AttrName
RULE: Stmt ::= 'while' Expr 'do' Stmt COMPUTE ...
... Expr.postType ...
... Stmt.code ...
... .label ...
... RuleFct ("PTG", RHS.Ptg) ...
SYMBOL Expr COMPUTE
... SYNT.preType ...
... INH.postType ...
... THIS.preType ...
... RuleFct ("PTG", RHS.Ptg) ...
Attributes in rule computations have the form
X is a nonterminal in the production of the rule. They refer
to the attribute
a of the tree node corresponding to
index distinguishes multiple occurrences of the nonterminal in the
production, counting from left to right starting at 1.
Rule attributes of the form
.b may be used in rule computations,
to simplify reuse of computed values. They are defined and used
within the computations of a single rule. They are not associated with any
In symbol computations attributes of the considered symbol are denoted using
THIS instead of the
SYNT.a for a synthesized attribute,
INH.b for an inherited attribute, or
leaving the attribute class to be specified elsewhere.
RhsAttrs construct, such as
is a shorthand for a sequence of attributes all named
one for each right-hand side nonterminal of the rule context
associated with the
computation. If there is more than one such nonterminal
the construct may only occur in function
calls, where it contributes part of the argument sequence,
DependsClauses(see Dependent Expressions).
If a symbol computation contains a
sequence of attributes is determined for each rule context
of the symbol individually. In combination with the predefined
may be used to specify a call pattern
that is instantiated differently for each rule context
(see Predefined Entities).
SymbolRef must occur in the production of the rule.
SymbolRef must be indexed if and only if the symbol
occurs more than once in the production.
The index of a
SymbolRef must identify an occurrence of the
symbol in the production.
SymbNames and indices may not be used in attributes of symbol
Rule attributes may not be used in symbol computations.
Each attribute has a certain type characterizing the values propagated by
Attributes that describe only postconditions of computations
without propagating a value have the predefined type
VOID types must be specified explicitly.
Each attribute has either the class synthesized (
if it is computed in all lower contexts of its symbol,
or it has the class inherited
INH), if it is computed in all upper
contexts of its symbol. Attribute classes are usually derived from
computations without explicit specifications.
AttrSpec ::= 'ATTR' AttrNames ':' TypeName [ AttrClass ]
SymSpec ::= SymbKind SymbNames ':' [ AttrSpecs ]
AttrSpecs ::= AttrSpecs ',' AttrSpecs
| AttrNames ':' TypeName [ AttrClass ]
AttrClass ::= 'SYNT' | 'INH'
ATTR code: PTGNode SYNT;
SYMBOL Expr, UseIdent: preType, postType: DefTableKey;
An attribute name specification (
determines the type and optionally the class
of all attributes having one of the
AttrSpec for a nonterminal determines the type and
optionally the class of attributes given by the
for all nonterminals given by
specifications override the type and the attribute class stated by
If the type of an attribute is left unspecified it is assumed to be
Note: Misspelling of an attribute name in a computation
leads to introduction of a
VOID attribute, and is usually indicated by messages on missing
computations for that attribute or illegal use of a
Note: The type of a non-
VOID rule attribute has to be specified
There may be several
ATTRspecifications for the same
AttrName provided their properties are not contradictory.
A specified attribute class must be consistent with all computations
of that attribute.
VOID attributes may not be used in value contexts.
The type specified for an attribute must denote an assignable C type that is
available in the generated evaluator.
LIGA does not check whether non-
VOID attributes are used
consistently with respect to their types.
Violations will be indicated when the generated
evaluator is compiled.