Depot4/Oberon Updates
1.8
- Additional module Dp4StrBuf for internal stream buffering
- Internal handling of SOURCETEXT revised, caused some interface modifications
- Some minor bugs have been fixed.
1.7
Version 1.7 is a minor update of Depot4. There was a change in the interface
of the runtime system. This will not really affect any written code but is very likely to cause
recompilations.
Changes in Depot4-Version 1.6 with respect to earlier versions
- 1 Changed internal interface
- 2 Refinement of comment format definition
- 3 Mapping module
Dp4Map
Version 1.6 marks a serious step in Depot4 development, which is also to be suggested by the gap
in numbering to its predecessor V1.4. For several reasons some essential design decisions have been
revised. That's why one has to face the unpleasant situation of some incompatibilities. Fortunately,
more advanced applications will be affected only.
Most relevant news is that there is an implementation of Depot4 based on Java
now. Both implementations understand the meta-language Ml4 without any differences, i.e., existing
translators can be ported simply by re-translation. Of course, this doesn't hold, if external
modules are involved. Sorrily, due to Java's parameter restrictions, substantially changes in
procedures interfaces are unavoidable usually.
Further on, there are the obligatory bug fixes and improvements.
1 Changed internal interface
This is the most significant change. The internal parse procedures are proper procedures now.
Their implicit result (targets) is converted into an additional var parameter. Experience shows
an increase in speed of about 30%. (The approbiate data fields come from the stack now and are
no longer allocated from the heap.)
Although this is mainly an internal issue, it may affect existing translators to a certain degree:
- Re-translation
Most Ml4 code needs simply re-translation only.
- Adjustment of individual procedures
If individual scanner procedures are used, their formal parameter lists must be adjusted.
See for Details.
2 Refinement of comment format definition
During development of the Depot4/Java system a significant shortcoming of the recently extended
comment definition format was detected. To overcome this, the escape symbol is changed from
backslash (\) into Dollar sign ($).
Additionally, comment definitions are handled in a stack-like fashion, i.e., the last definition is searched
for firstly. As before, four different fromats are allowed.
There is a meachnism for handling pseudo comments (directives) now.
Comment formats may be defined as follows:
- One simple, possibly nested comment format: no change
e.g. DefCom('(*', '*) ')
- Additional comment formats (also nesting possible): first string starts with control sequence,
enclosed in $ $
e.g. DefCom('$+${', '} ')
- Preceding definitions can be overriden by defining the position of the new format,
DefCom('$1${', '} ')
makes this the top record (all other are deleted)
- Delete just the last definition:
DefCom('$-$', '')
- Non nested comment formats need always the extended form, starting with "$?-", where ?
stands for one of the characters "+", "-", "1"..."4"
e.g. DefCom('$1-$/*', '*/ ')
for C style comments (overriding the default)
(an "*" in this position indicates nesting)
There is the possiblity to invoke
a non terminal NONTERM
to consume the text stretch following the opening. Any remaining text will be skipped as usual, i.e. the closing must not
be consumed by NONTERM
!
E.g. DefCom('$+:NONTERM${$', '} ')
for TurboPascal like directives
Remark: Any targets generated by NONTERM
will be ignored (if not saved via parameters or global variables).
Examples:
- Java comments
DefCo('$1-$/*', '*/ '); DefCo('$+-$//','\n ');
suffices to define comment formats for Java. However, if there is a need to handle documentational comments differently, one has to add
DefCo('$+-$/**', '*/ ');
Be aware of the sequence
DefCo('$+-$/*', '*/ ');... DefCo('$+-$/**', '*/ ');
because otherwise any comment starting with "/**" will be already skipped as one of form "/*".
- Handling of pseudo comments
Comment format definition:
DefCo('$+:NtDirect$(*!', '*) ');
Non terminal definition:
NtDirect=
GLOBVAR USE traceStat: BOOL;
('notrace'|'trace'|(*ignore*)); traceStat:= c=2;.
could be used to analyse
... (*!trace version 33 29-FEB-00 *) ...
3 Mapping module Dp4Map
Due to different naming conventions (e.g. Oberon module identifiers versus Java package names) a
mapping facility seems useful. Dp4Map
delivers this functionality.
DEFINITION Dp4Map;
IMPORT Dp4Base;
PROCEDURE clrMaps*;
(* clears/deletes all mappings *)
PROCEDURE getMap*(s: Dp4Base.SymbolDesc): Dp4Base.tNode;
(* delivers a mapping for string s (or s if there is none) in TXT format *)
PROCEDURE getSMap*(VAR t: Dp4Base.SymbolDesc; s: Dp4Base.SymbolDesc);
(* as above, but result t is of Ml4 type SYM *)
PROCEDURE setMap*(s, t: Dp4Base.SymbolDesc);
(* defines string t to be the mapping of s *)
END Dp4Map.
The Ml4 to Java translator heavily exploits those mappings, e.g. Dp4Map.setMap('Dp4OP', Dp4.OP')
.
Adjust formal parameter list (Details)
Parsing procedure outline in versions <1.6 (no longer valid):
PROCEDURE expl(VAR yyNT: yT.NonTerm; VAR yyPrs:yB.Prs):yB.trgts;
(* declarations *)
BEGIN
(* parsing actions *)
IF yyPrs.A THEN NEW(yy0tg);
(* target generation *)
END;
RETURN yy0tg
END expl;
The internal target type is now defined as:
TYPE SymbolDesc* = ARRAY SymLen OF CHAR;
trgts*= RECORD trg0*: SymbolDesc;
trg1*,trg2*, trg3*,trg4*,trg5*,trg6*,trg7*,trg8*: tNode END;
According, the outline is changed to:
PROCEDURE expl(VAR yyNT: yT.NonTerm; VAR yyPrs:yB.Prs; VAR yy0tg:yB.trgts);
(* declarations *)
BEGIN
(* parsing actions *)
IF yyPrs.A THEN
(* target generation *)
END;
END expl;
(10-Mar-1998)