[ooc-compiler] wrapper to SYSTEM.VAL

[Norayr C. <ch...@gm...>]

Hey,
I am porting Ulm's Oberon Library to use with ooc.
All separate definition/implementation modules are already merged, and I
have managed to compile some set of modules.
Every occurence of INTEGER also must be changed to the LONGINT. I don't deal
with it now, because LONGINT in Ulm's system also may be used as an ADDRESS,
so, I would like to review every occurence and change it according to the
context later.

So, most important parts of the library use the SYSTEM module described
here: http://www.mathematik.uni-ulm.de/oberon/current/lib/man/SYSTEM.html
and SYSTEM.UNIXCALL calls.
I have created a wrapper module ULMSYSTEM.Mod, which currently has the
following state:

MODULE ULMSYSTEM;
(* Norayr Chilingaryan, 2010
This module is a wrapper which emulates SYSTEM module of Ulm's Oberon
Library *)

IMPORT SYSTEM;

TYPE INT16* = INTEGER (*oo2c's INTEGER is 2 bytes long, norayr*) (* 2-byte
integer type *);
TYPE ADDRESS* = SYSTEM.ADDRESS (*in oo2c SYSTEM.ADDRESS is 4 bytes long on
32bit systems and 8 bytes long on 64bit systems, norayr *) (*
LONGINT-compatible & traced by the GC *);
TYPE UNTRACEDADDRESS* = SYSTEM.ADDRESS (* see above line, norayr *)(*
LONGINT-compatible & ignored by the GC *);
TYPE BYTE* = SYSTEM.BYTE; (* added by me because of existence of BYTE in
ULMs library. For instance, needed by Types.Mod, norayr *)

PROCEDURE TAS*(VAR flag : BOOLEAN): BOOLEAN;
VAR tmpfl: BOOLEAN;
BEGIN
   tmpfl := flag;
   flag := TRUE;
   RETURN tmpfl
END TAS;

PROCEDURE VAL*(type: AnyTypeName; value: AnyType) : type;
BEGIN
RETURN SYSTEM.VAL(type, value);
END VAL;

END ULMSYSTEM.

So, is it possible in principle to create a VAL wrapper, by taking in
consideration that it is implemented on the compiler level actually.
Usually, modules in Ulm's library import SYSTEM by using SYS alias, like
this:
IMPORT SYS:=SYSTEM
which I replace by SYS := ULMSYSTEM
It is of course possible to change every occurence of SYS.VAL by the
SYSTEM.VAL, but I consider it as a dirty option.
It is also possible to wrap VAL by using C implementation, what I also would
like to avoid for now.

Any ideas, Stewart? (or anybody besides you still read this mail list?)

Sincerely,
Norayr