Parametric polymorphism - Oberon/F

Mike Leddy (mike@ultranet.com.br)
Wed, 27 Nov 1996 01:01:32 -0300

I got a hold of the paper "Lightweight Parametric Polymorphism for
Oberon" http://www.fit.qut.edu.au/~szypersk/jmlc.ps.gz
and after reading it a couple of times (it didn't quite sink in during
the first pass) I very much liked the ideas.

I'm from a C++ background, and am considering the switch to Oberon with
the general aim of improving software quality. I decided to experiment
with some of the concepts a little with Oberon/F (educational version
1.2.1 for Windows) - it seems that the compiler has some shortcomings.
Here's the simplest version that demonstrates the problem.

MODULE PrivTest;
IMPORT SYSTEM;
TYPE T = POINTER TO TDesc; TDesc = RECORD x: INTEGER END;
VAR t: T; td: TDesc; i: INTEGER;
BEGIN
td := SYSTEM.VAL(TDesc, t^); i := td.x; (* OK with intermediate
variable *)
i := SYSTEM.VAL(TDesc, t^).x; (* ERROR - incompatible assignment *)
END PrivTest.

I am very satisfied with the general quality of Oberon/F, this is the
first disappointment that I've encountered. Why incompatible assigment?
Is there a reason for this counterintuitive behaviour? Has it been fixed
in the comercial product? What happens with other Oberon compilers? Any
comments?

The paper suggests that a construct such as:

NEW(SYSTEM.VAL(POINTER TO TDesc, t));

is standard Oberon-2 - It seems very likely to me that most existing
compilers w9ould certainly reject this. NEW would need to be smart enough
to delve into the parameters of SYSTEM.VAL or some type of special
case extension would need to be made for SYSTEM.VAL (rather like using
a constant CHAR string where an ARRAY OF CHAR is expected). Oberon/F
doesn't get very far and complains about POINTER TO ie. factor starts
with incorrect symbol.

Coming from a C++ background I grew to 'love' the STL (standard template
library), it simplified implementation greatly and I could easily live
with the code bloat. An extension to Oberon/F (or a Preprocessor) which
could give parametric polymorphism would be a very significant
improvement for developers. Is there any chance that Oberon Micro Systems
might get actively interested in this?

Regards,

Mike Leddy (Almost converted to the Oberon way).