Depot4 User Manual(E)

    previous         next         contents

Appendix D: Implementation specific issues

This appendix comprises implementation specific issues of the Depot4 system.

D1 Java

D1.4.3 Additional class terminals

D1.5 Configuration

D1.6 Implementation of external modules

D1 Java

Originally, Depot4 was developed on base of Niklaus Wirth's Oberon system. When Java appeared on the scene it was soon realized an attractive migration target. The move was performed surprisingly fast. For a while (until the 1.8.x versions), both implementations were kept fully source code compatible and maintained in parallel. This origin may explain some seeming singularities in naming and structure.
Depot4/Java was implemented first time with JDK 1.0.2. The system core relies on such basic features (and packages) only which have been available form the very beginning. Thus, one can expect generated translators to run with any of the various Java versions. On the other hand, the user interface, i.e. a fairly simple integrated development environment (IDE) has been continuously improved due to the availability of new features, e.g. the Swing packages.

D1.1 Installation

Depot4 expects a functional Java installation (Java Runtime Environment - JRE). This is not part of the distribution. To exploit its full capabilities a Java compiler (part of the Java Development Kit - JDK) is also required.
Depot4/Java is a rather compact software which could easily be shipped on a 1.4 MB floppy (including all sources). Installation is simple. The code is packed into one or two JAR files. (For details see the accompanying information.) Store them in an appropriate place and make them visible to the JVM by adding them to its classpath.

The different modes of use:

Application of Depot4 generated translators without IDE
Then the installation is complete. One may use Dp4Run as main class.
Building Depot4 based translators
This needs a Java compiler in addition. The simplest way to make the compiler accessible is to add the tools.jar archive from the JDK to the classpath.
However, the compiler is in the sun.tools.* package and thus, not part of the supported, public interface. I.e., in certain environments or with future releases additional adaptional efforts may be requested.

D1.2 Metalanguage (Ml4)

To allow a fines control of module/rule to Java package mapping, the translator supports a package directive. Its use will override the default mapping.

Default mapping: Rule/module names which contain a non-empty prefix, i.e., there is a small letter or digit followed by a capital letter will be placed in package 'prefix'.
Example: AlfaBeta -> class AlfaBeta in package Alfa; alfa2BeTa -> class alfa2BeTa in package alfa2
Package directive: Placing (*!package=xx.yy.zz ...*) anywhere in the Ml4 code you can define a package for the rule/module.
(*!nopackage ...*) surpresses the standard package placement.

D1.3 User Interface (IDE)

Depot4/Java comes with a standard interface that allows you to produce translators, to apply, and to debug them.
The initial settings of this interface can be defined in the depot4.cfg file which is part of the distribution. It can be inspected and edited in every editor. If you do not want to change the default settings this file can be deleted.
In principle, the IDE can run as an applet, too. However, this is not recommended in general because the applet security policy restricts use significantly.

There are two versions of the development environment:

Simple AWT based interface program: If
Java version: from 1.0.2
package name: Dp4.If
main class: Dp4.If.depot4 (extends java.applet.Applet)
alternative main class: dp4 (a wrapper for the above without explicit package, needed sometimes)
Swing base extended interface program: ide
Java version: from 1.2 (Swing)
package name: Dp4.ide
main class: Dp4.ide.Main (extends java.applet.Applet)

Both the environments take care that a newly translated module is subsequently applied. There is no need to restart.
One may add further (and even remote) locations where to search for modules to load. Depot4 has a network loader which supports the use of remotely stored translator classes. Given the package name as in Java's package statement, e.g. "my.nice.pack" and a full quailified URL of an appropriate directory, e.g. "file://localhost/classes/" (trailing slash may be omitted) a rule "ThisRule" will be searched for as

ThisRule
This.ThisRule
my.nice.pack.ThisRule
file://localhost/classes/ThisRule.class
Dp4.ThisRule

(If the name of the rule/module has no valid prefix as Thisrule, THISrule, etc. point 2 is skipped.)

The simplest way for direct use is the command line interface provided by Dp4Run.

Dp4Run root infile outfile

root: the root production (nonterminal)
infile: the source file name
outfile: the target file name

Example: java -classpath=... Dp4Run Ml4jT ml4/Example.ml4 generated/java/Example.java

If present, Dp4Run evaluates a configuration file Dp4Run.cfg. Inspect the source code for learning how to create customized versions of this class.

D1.4 Library classes

All library classes are part of the Dp4 package.

D1.4.1 Dp4Util

public static String Date(): Delivers the current date in standard format. The standard date format is specified by the Java runtime. It can be set explicitly in the system property "depot4.date.format".
Important: This functionality requires a Java version of 1.1 or higher at least.
public static String getPrefix(String id): Determines the prefix of a name, e.g., getPrefix("Dp4Util") returns "Dp4",
may be empty if there is no capital letter following a digit or small letter in the argument
public static String getSuffix(String id): Opposite to getPrefix, e.g. returns "Util" in the above example,
returns the argument if there is no prefix
public static String toUpperC: Converts all letters in the argument into uppercase.
public static String toLowerC: Converts all letters in the argument into lowercase.
public static String up1letter(String t): Converts only the first character of the argument into uppercase if it is a letter.
public static String id2pack(String id): Constructs a package name (prefix(id)+"."+id) from the argument if the prefix is not empty, otherwise returns the argument.
public static void makeFileDir(String id): Makes a new subdirectory in the current working directory. (Throws a runtime exception if this is not possible.)

D1.4.2 Dp4Tools

This module comprises some useful procedures that are used mainly by the interface.

public static trgts translate(Dp4.Source s, Dp4.NonTerm ROOT): Translates the source s by use of the rules defined by ROOT.
public static trgts translate(Dp4.Source s, String ROOT): Same as above, but the root is given as string.
public static boolean isOk(): Indicates the success of the translation (set by translate)
public static void setCap(boolean state): If set true, capitalization in identifiers is significant.
public static boolean isCap(): Returns true if capitalization in identifiers is significant.

D1.4.3 Additional class terminals

There are some additional class terminals shipped with this release of Depot4.

identJava: Accepts identifiers excatly due to the definition of the Java language.
identPascal: Accepts identifiers consisting of letters and digits, whereby only the first 8 characters are significant. Capitalisation is insignificant. (These were the original rules of Pascal.)
identX: Accepts identifiers consisting of lettters, digits, and '_', starting with a letter. This class may serve as superclass for more specific implementations (such as the two above).
idForApplet: This is a specific implementation of ident which does not access the local file system and thus, cannot read an exclusion list from file. As the name tells it is intended for use in applets.

D1.5 Configuration

A certain Depot4 installation can be configured by means of the class Dp4.config. This class is intended for costumization and may be changed.
By default it contains the paths for the standard class terminals. Those ones that are not used can be removed. One can also add further substitutions.

Hint: Any of the classes can be sustituted by creating a new class file and adding the package's root directory to the classpath.

D1.6 Implementation of external modules

Because of the different modularization levels (modules vs. classes) in Ml4 and Java, the implementation of external modules needs some care. Static methods and types (classes) must be loacted in different classes. External type names must be implemented in a class called modulename_typename. Of course, module names can be mapped on any complete (i.e. including the full package name) class names.

Example

Ml4 text:

IMPORT External;
ExamplRule=
  VAR v1, v2: External.T1;
       v3: External.T2;
   ...
  External.M1(v1); ... v2:= External.T1("t"); ...
  v2.M3();

Java text:

public class External {
  public static void M1(External_T1 t) { ... }
  public static External_T1(String s) { ... }
}
public class External_T1 {
  public void M3() { ... }
}
public class External_T2 {... }

Type mappings of Ml4 types on Java types

INTEGER on int

BOOLEAN on boolean

REAL on float

SYM on java.lang.String

TXT on Dp4.tNode

TARGET on Dp4.trgts

The mapping of records, arrays and FLEX arrays is more difficult as specific access methods are generated. So it may be useful to define a nonterminal containing only the Ml4 type definitions and let the system generate the appropriate Java code. (Hint: One can use the translator by selecting "Ml4jT" as root.)

    previous         next         contents