The compiler


next up previous
Next: Run-time library and built-in classes
Up: Implementation
Previous: Session identifiers

The compiler

The compiler is written in CLisp, an OS/2 Lisp implementation. Any reasonable symbol-processing language would do; CLisp just happened to be readily available out of the restricted choice of OS/2 implementations.

Like most compilers, Web-O-Matic consists of a tokeniser, parser, and a code-generator. The tokeniser and parser are fairly normal, though complicated somewhat by the need to recognise WOM commands within an arbitrary mixture of HTML and plain text.

The code-generator takes the parsed WOM file as an abstract syntax tree, transforms it, and emits it as Object Rexx. The code-generator has two main jobs. One is to convert the equations to Object Rexx code, checking for dependency loops, simultaneous updates, and so on. The second is to translate the instantiation commands, including the code for setting initial values of attributes.

The code-generator sometimes has to subclass existing class definitions. For example, if a WOM program contains a WOMForm with some OnSubmit equations, these equations are translated into code which must be obeyed whenever the form is resubmitted. The most convenient place to put this code is inside an update method belonging to the form. Since all forms will have different update methods, they all need to be implemented as different classes.

Only the output stage is specific to this language, and so it would be easy to emit Java or some other OOP language instead. If (as is usually the case) the target language does not provide long-lived instances at the operating-system level, then some way must be found to simulate them. One solution considered for Java is to have a Java process continuously-running as an ``instance manager'' acolyte to the server, responding to requests to create new instances, delete old ones, and call methods. Another solution is to use one of the packages now being developed for providing persistent objects, such as Object Design Inc's ObjectStore system [Object Design].

With rather more work, one could also generate code in a non-OOP language, though this would require some careful run-time support to maintain state between transactions.


next up previous
Next: Run-time library and built-in classes
Up: Implementation
Previous: Session identifiers



Jocelyn Ireson-Paine
Sat Oct 12 23:35:52 BST 1996