New Features of Eli4.0
 
In previous LIDO versions non-literal terminals were considered to
be symbols that may have attributes - several inherited attributes
and at most one that is supplied when the node is constructed. Hence,
non-literal terminals may have upper symbol computations, and their
attributes may be used in adjacent and in remote contexts.
In the new LIDO version a non-literal terminal, like Ident in a rule
RULE decl: Declaration ::= Ident ':' Type END;
may supply a value to computations associated to the RULE context.
That value usually describes a property
of the corresponding input token, e. g. the encoding of an identifier
determined by the scanner and passed through by the parser.
The type of the value supplied by a non-literal terminal is specified
by a terminal specification like
TERM Ident : int;
The above construct can be omitted if the type is int, i.e.
in all cases where the terminal is provided by an Eli generated
scanner. Types other than int may occur if tree nodes are
created by explicit computations.
The value of a non-literal terminal of a certain context can be
used in computations associated to that context, e. g.
Declaration.Key = DefineIdn (INCLUDING Root.Env, Ident);
There the name of the non-literal terminal stands for its value.
If there are several occurrences of a non-literal terminal in a
production, their values are distinguished by indexing their names,
e. g. Ident[1], Ident[2], ...
The values of non-literal terminals may also be used in symbol computations.
There the notation is TERM, TERM[1], TERM[2], ..., e. g. in
SYMBOL Use COMPUTE
SYNT.Key = KeyInEnv (INCLUDING Root.Env, TERM);
END;
In order not to immediatly invalidate existing specifications LIGA
still accepts most uses of old style terminals and internally
transforms them into new style terminals.
The TRANSFER construct provided by former LIDO versions is no
longer available.
The new LIDO version requires semicolons (';') to terminate RULE
and SYMBOL specifications and computations. In previous versions
of LIDO the ';' after the last specification or computations
could be ommited.
If computations are to be executed while the input is read
they are now to be marked BOTTOM_UP, e.g.
printf ("immediate reply\n") BOTTOM_UP;
instead of using a LIGAPragma.
Bottom-Up attribute evaluation, i.e. attribute computations during
abstract structure tree construction ("parse-time") is no-longer the
default strategy used in Eli. To switch to Bottom-Up evaluation it has
to be activated in an .ctl specification (ORDER: TREE BOTTOM_UP),
See Order Options of LCL - Liga Control Language,
or requested by a BOTTOM_UP specifier in LIDO
See Computations of LIDO - Reference Manual.
Symbols that describe computational roles (e.g. RangeScope)
are now explicitly distinguished from tree grammar symbols
by using the keyword CLASS before SYMBOL, e.g.
CLASS SYMBOL RangeScope COMPUTE ... END;
Symbols that occur in the tree grammar (tree symbols) are specified
as TREE SYMBOLS:
TREE SYMBOL expr COMPUTE ... END;
With this extension Liga can then check whether incidentally the name
of a tree grammar symbol coincides with a CLASS symbol, that may be
obtained from a library module.
Liga will issue warning messages if there is an INHERITS from a tree
grammar symbol, or if a CLASS symbol is also a tree grammar symbol.
For upward compatibility symbol specifications without TREE or CLASS
prefix are still supported.
The LIGAPragma notation of former versions has been substituted by
simpler notations (see Outdated constructs of LIDO - Reference Manual).
In previous LIDO versions terminals were allowed to be used as
LISTOF elements, e.g.:
RULE: Idents LISTOF Identifier
This facility is not supported anymore.
An alternative token <- for DEPENDS_ON is accepted.
If the source coordinates of contexts are used in computations, the
identifiers LINE, COL, COORDREF must occur directly
in the Lido text. They may not be introduced by macros defined in a
`.head' file. As a consequence the library module Message has been
removed.
If there is no such coordinate usage in a certain
context, that information is not stored in the tree node.
The storage needed for the tree is reduced by this means.
Chain Productions of the form
Production ::= SymbName 'IS' SymbName
are no longer valid.
Productions using ::= now have the same meaning as the former IS.
The effect of hiding such productions from the parser
is achieved by mapping the concrete grammar to the tree grammar.
Specifications of the form
Specification ::= 'TYPE' TypeName [Extern] ['LISTEDTO' TypeName]
Extern ::= Literal
are no longer valid.
TypeNames are now simply introduced by their use.
Computations of the form
Computation ::= 'CHAINSTART' ChainAttr
are no longer valid.
The keyword CHAINSTART is now attached to the computation that starts
the chain.
The keyword STATIC (equivalent to COMPUTE) is no longer valid.
The := token (equivalent to =) in computations is no longer valid.
The keyword CONDITION in front of plain computations (computations
that do not compute an attribute) is now omitted.
|
