> 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?
Your C++ background is showing... I don't see any reason why
'SYSTEM.VAL(TDesc, t^).x' *should* work. In C++ '.' is an
operator; but in Oberon it is a *selector*. From sec 8.1 of the
language report,
"A designator consists of an identifier referring to a constant,
variable, or procedure. This identifier may possibly be qualified
by a module identifier (see Ch. 4 and 11) and may be followed by
selectors if the designated object is an element of a structure"
"counterintuitive" is in the eye of the beholder :)
> The paper suggests that a construct such as:
>
> NEW(SYSTEM.VAL(POINTER TO TDesc, t));
>
> is standard Oberon-2
You have to be careful doing *anything* with the module SYSTEM. By
definition, SYSTEM is system dependent. Converting one pointer type
to another is especially dangerous as it may corrupt the garbage
collector.
I'm not even sure what 'NEW(SYSTEM.VAL(POINTER TO TDesc, t))' is
supposed to do... which identifier is supposed to refer to the
record allocated by NEW()? t?
SYSTEM.VAL is provided in cases where you *intentionally* want to
break the type system. I haven't read the paper you mentioned, but
it seems to me to be a dangerous way to implement generics.
> 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?
I can't speak for Oberon Microsystems, but lack of generics is a weakness
in Oberon. Generics can be simulated using inheritence, but that isn't
satisfactory in all cases. IMO, at this time, a preprocessor would be
preferable to a proprietary extension. But supporting generics should
be a definite consideration in the evolution of the Oberon language.
(* See Michael Franz's paper on the Lagoona language for a potential
"solution" to this problem,
http://www.ics.uci.edu/~franz/Lagoona-ics-tr-96-40.ps *)
-- Eric--- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Those who know that they are profound strive for clarity. Those who would like to seem profound to the crowd strive for obscurity. He is a thinker; that means, he knows how to make things simpler than they are... - Friedrich Nietzsche ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~