> 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.
Thanks for your interest in our work and the encouraging comment!
> 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?
I agree that the message "incompatible assignment" is misleading. The Oberon
syntax does not allow a function call (and SYSTEM.VAL has functional form,
although it behaves exceptionally) as part of a designator, i.e.,
x := f(y).z
is generally illegal, regardless of what f is.
The error message is caused by the compiler not expecting a "." at this point
and thus concluding it must the end of the LHS expression. Before going on,
it type checks the assignment and reports an "incompatible assignment"
error, as it "thinks" you are trying to assign a record type to an integer
type. It then supresses the ". unexpected" error, as it never produces
multiple error messages for the same single textual source position.
I hope this helps to understand what happened. The restriction of no function
calls in designators may need some getting used to, as it is not present in
the C line of languages - it was always part of all Pascal-line languages.
(This may have been relaxed by ISO for their ISO Modula-2; not sure there.)
On the use of SYSTEM see my remarks further below.
> 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.
Our apologies. We used this notation as it gets very close to what the
rewriter really has to do to conform with existing compilers without going
into exceeding detail in the paper. Note that SYSTEM is _not_ part of the
standard language proper and may have different interpretations under
different implementations. However, SYSTEM.VAL forms part of the recommended
subset of SYSTEM that every compiler should have.
To conform with most existing compilers, the rewriter would have to use a
proper type name rather than a constructed anonymous type - and if none was
available it would have to introduce the definition for a synthesised free
name of the required type. In turn, it would generate
NEW(SYSTEM.VAL(Ptr, t))
with Ptr = POINTER TO TDesc - this is accepted by current Oberon compilers.
Note that there really is no magic - NEW does not try to interpret the type
of its argument at run-time (in fact, it just couldn't in most cases, as NEW
is often applied to pointers initialized to NIL - NIL does not belong to any
specific pointer type).
Instead, the compiler translates NEW(p) into a runtime call such as Alloc(p,
t) where t is a pointer to the type descriptor for the required type. By not
exposing this primitive to the programmer, NEW is type safe - unless you use
SYSTEM to tell the compiler you want an object of a different type, of
course: then it is up to you to make sure that it is OK to do so.
> 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?
We are currently working on a small but productive and hopefully elegant
libarary of parametrically polymorphic containers and the like. First of all,
this will serve to validate that our design along the right lines. Secondly,
it will make this new language feature saleable. At this point in time it is
too early to say anything but that Oberon microsystems is seriously
interested ;-)
> Mike Leddy (Almost converted to the Oberon way).
Great!!
Cheers,
- Clemens
mailto:c.szyperski@qut.edu.au
http://www.fit.qut.edu.au/~szypersk