Frequently Asked Questions and Answers
 
Further hints for updates of specifications can be found in
New Features of Eli Version 4.1, and in
New Features of Eli Version 4.0.
4 |#include "envmod.h"
(test.c) cannot find include file: "envmod.h"
Eli no longer automatically extracts all modules that are mentioned
somewhere in #include files.
For example, in order to add the envmod module to a specification,
some .specs file must contain the line $/Name/envmod.specs.
($ in this context is a shorthand for the package directory in the
cache currently being used.)
> Am I correct in noting that the link between the key table and the
> string table containing non-literal strings was possible via the
> following (in Eli3)
> ATTR Key: DefTableKey;
> SYMBOL xName INHERITS IdDefNest END;
> SYMBOL xIdent INHERITS IdPtg END;
>
> RULE Name: xName ::= xIdent
> COMPUTE
> xName.Ptg = xIdent.Ptg;
> xName.Sym = xIdent.Sym;
> END;
There are two different tasks:
-
Consistent renaming for name analysis (that's what Key's are for)
-
Output text generation with Ptg (based on the string representation)
There is Module Library support for both tasks.
In your example you use
-
IdDefNest for name analysis
-
IdPtg for output text generation for identifiers
IdPtg computes an inherited attribute Ptg
containing the PTG representation of the identifier to which IdPtg
is inherited.
IdPtg could be inherited to terminals (as you do above) in earlier
Eli versions.
The precondition for the application of IdPtg is that the symbol
to which IdPtg is inherited provides an attribute named Sym
containing the string table index of the associated identifier.
Since Eli Version 4.x, inheritance to terminals is no longer possible.
That is the only difference for your application.
So you simply have to move your PTG computation one level up to the symbol
xName.
This should give you:
SYMBOL xName INHERITS IdPtg END;
RULE Name: xName ::= xIdent
COMPUTE
xName.Sym = xIdent.Sym;
END;
which even looks a bit simpler than the 3.8 solution.
> I'm surprised that C_STRING_LIT now uses mkstr instead of c_mkstr.
> What's the reason?
c_mkstr had the problem that if the string in the source text
contained a null character, that string was silently truncated:
"abc\0def" became "abc"
This is a consequence of the string storage module implementation, and
could only be avoided by placing a high cost on all string operations.
To avoid the problem, c_mkstr was changed to report an error
if it found "\0" in a string.
The changed c_mkstr no longer implements C strings, so it
could not be used as the processor for C_STRING_LIT.
|
