[Oberon] Clarifying type compatibility in Oberon-07
joerg.straube at iaeth.ch
Sun Oct 8 07:26:20 CEST 2017
Unnamed entities (or is it structural equivalence?) can create troubles.
TYPE DotType = PROCEDURE (col, x, y: INTEGER);
VAR dot: DotType;
PROCEDURE myDot(x, y, col:: INTEGER); BEGIN END myDot;
dot := myDot; (* allowed in Oberon, structurally equivalent, but the formal parameters are totally scrambled *)
Here you see, how the unnamed formal parameters (or the structural equivalence) can generate a complete mess!
The compiler should not only check the types of the formal parameters but their names as well.
Or: to be extremely consequent(!!) A PROCEDURE (especially those to be used as variables) should get a named TYPE. Something like
PROCEDURE myDot = DotType; (* totally new syntax *)
But this is too far off-topic.
> Am 08.10.2017 um 07:12 schrieb Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:
> > On Sun Oct 8 02:26:53 CEST 2017 Chris Burrows wrote:
> > If the programmer has chosen to use anonymous arrays it might well be reasonable to assume
> > he is not concerned about name equivalence so why should he be inconvenienced but prohibiting
> > assignments? Surely not just because it conflicts with somebody else's personal taste?
> It all boils to the question of whether we view the text “ARRAY 10 OF INTEGER” in an anonymous array declaration as
> a) a name in its own right
> b) a name with a parameter 10
> c) not a name (anonymous entity)
> Different programmers will have different points of views on this.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon