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).