[Oberon] Clarifying type compatibility in Oberon-07

[Jörg]

Unnamed entities (or is it structural equivalence?) can create troubles.
See yourself

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.

Jörg

> 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.
> 
> -AP
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171008/12c4ef5a/attachment.html>