Depot4/Oberon Updates


1.8


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:

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:

Examples:

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;


up

(10-Mar-1998)