[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

Hi Jörg,
In essence you are right. A more detailed response will follow. Here I just add some brief comments. See inline comments.

  > On Thu Oct 5 17:25:20 CEST 2017 by Jörg joerg.straube at iaeth.ch 
  > Hi Andreas
  > Of course we could do so, but I wonder why?
  >
  > If I understand you correctly you want to allow the following
  >
  > VAR
  > a: ARRAY 30 OF CHAR;
  > b: ARRAY 30 OF CHAR;
  >
  > a := b;

Yes, this would be one example. But there are also other (roughly similar) cases involving parameters and local variables.

  > Currently, this is not allowed, because there are several ways to allow this already
  > Method 1:
  > VAR a, b: ARRAY 30 OF CHAR;
  >
  > Method 2:
  > TYPE String30 = ARRAY 30 OF CHAR;
  > VAR a: String30;
  >   b: String30;


  > We should not change the language. At least not in this case. What could be a practical benefit of it?
  > NW allows assignment of different ARRAY types only in case of open arrays. This is reasonable as the formal
  > parameter accepts different types.

Acknowledged. I just wasn’t sure whether a) it should be allowed but accidentally isn’t or whether b) it should not be allowed, and therefore isn’t. If I read you correctly, in essence what you are saying is that one should not allow structural equivalence when name equivalence suffices (and represents cleaner programming style). It’s not that one can’t, it’s that one doesn’t need to..

  > PROCEDURE Test(VAR open: ARRAY OF CHAR);
  > VAR local: ARRAY 17 OF CHAR;
  > BEGIN
  >   local := open  (* exception allowed by report *)
  >   open := local  (* not allowed. Here we could discuss whether we should allow this as well *)
  > END A;


Yes, but there are also cases where the formal parameter does *not* have to be an open array parameter, as in the example below.

In this small example, procedure P actually compiles without an error message, because both the variable array parameter ‘a’ and the local variable ‘local’ are of the same type (namely type A, name equivalence here). But when *calling* P with an actual parameter ‘y’ that is only structurally equivalent to the formal parameter ‘a’ of procedure P, an “incompatible parameters” compiler error is generated by the Oberon compiler. After your comment above, it is now clear why - namely for the exact same reason as in your example above: the formal parameter ‘a’ and the actual parameter ‘y' just are not assignment compatible.

MODULE M;
  TYPE A = ARRAY 3, 2 OF INTEGER;
  VAR x: A;
    y: ARRAY 3, 2 OF INTEGER;

  PROCEDURE P(VAR a: A);
    VAR local: A;
  BEGIN a := local
  END P;

BEGIN
  P(x);  (*correct*)
  P(y)   (*incompatible parameters*)
END M.

  > Jörg

Still, it may be worth pondering over this question some more. I just don’t have a good enough reason yet :-)

What I do know that it is easy to implement the newly proposed rules as outlined in the appendix below (just a few lines).

As I said, there will be a longer response on this (there have been some private discussion on this topic..)

Regards,
Andreas


Appendix: The two proposed rules discussed in this response are:

Same Types

Two variables a and b with types Ta and Tb are of the same type if
....
*4. Ta and Tb are array types with same element types and lengths
 

Assignment compatible

An expression e of type Te is assignment compatible with a variable v of
type Tv if one of the following conditions hold:
....
*8. Tv is ARRAY n OF Ta, e is ARRAY OF Tb, where Ta and Tb are the same type




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171005/989432cb/attachment.html>