Re: [Gm2] equality, inequality tests and structured types

[Andreas Fischlin]

Hi Gaius,

AFAIK no, it is definitely NOT allowed. It would be basically impossible given all the conventions that are very widely used in Modula-2. Ex.:

    VAR x,y: RECORD
                      ...
                      s: ARRAY [0..31] OF CHAR;
                      ...
                     END;

Then the semantics of a test such as

     IF x = y THEN
        ...

would be very ambiguous. Why? Take the convention of 0C as a string terminator. Then x and y might actually store the same string, but do their history contain currently after the 0C char some other characters, wich would require a really meaningful (in)equality test to consider the actual semantics of strings. A mere memory block comparison would never support safe program semantics. Moreover, considering the convention to not directly support in Modula-2 equality tests of strings, suddenly implicitly allowing for this within structured types would not make sense.

Moreover, the semantics of a relational test involving record structures with variants (RECORD  ... CASE  ... constructs) depending on current values of a tag field would be even more complicated, consider only e.g. relation of a CARDINAL vs. an INTEGER variant. All blowing up the compiler tremendously.

To sum up: For all these reasons I do strongly argue against allowing of any (in)equality testing of structured objects.

BTW, in all Modula-2 reports Wirth excludes implicitly such tests (Wirth, 1981 = PIM1 .. Wirth, 1988 = PIM4; e.g. PIM2: section 8.2, p. 149-151; PIM3: section 8.2, p. 152-154).

On the other hand, this does not apply to pointers to structured variables, which is also consistent with other concepts inherent in the Modula-2 language design.  _expression_ compatibility (in this case a boolean _expression_) is not problematic for all these object types. The word compatible is often misleading, since it may encompass different "levels" of compatibility:

1) identity
2) _expression_ compatibility
3) assignment compatibility

where any higher level implies all lower levels.

I would argue that any Modula-2 implementation should support (in)equality tests at level 1. Yet, please note, the identification of this level is more tricky than it may appear at first glance. For instance, the following construct

    TYPE
      MyInt1 = INTEGER; MyInt2 = INTEGER;
    VAR
       x1: MyInt1; x2: MyInt2;

Depending on the compiler's implementation, x1 and x2 may be considered of the same type or of a different type and accordingly be at level 1 or only at level 2, depending on how actual the algorithm, which compare types is actually implemented (e.g. Wirth, 1985; Gutknecht, 1985).

Given the relevance of such ambiguities Wirth was then willing to clarify some of these issues in his brief amendments (Wirth, 1984) to the original Modula-2 reports in PIM1 and 2 (Wirth, 1982 = PIM1; Wirth, 1983 = PIM2). Wirth (1984) stated:

1.1 The types of a formal VAR-parameter and that of its corresponding actual parameter must be identical (i.e. not merely compatible). This rule is relaxed in the case of a formal parameter of type ADDRESS, which is also compatible with all pointer types, and in the case of the type WORD, where the compatible types are specified for each implementation.

1.4 ... Assignment and test for (in)equality are applicable to opaque types.

These amendments were integrated into the two later editions (Wirth, 1985 = PIM3; Wirth, 1988 = PIM4).

(In)equality tests should always work for objects of identical types (level 1) and should also work for special cases with special compatibility rules such as SYSTEM.ADDRESS being compatible with any opaque and any pointer type (any PIM). However, since characteristics of types exported from SYSTEM may be implementation dependent, and because SYSTEM typically requires anyway extensions with newer hardware architectures etc., this may of course also vary with the implementation. To quote Niklaus Wirth "Standards are then agreed, if they have become irrelevant" (AFAI can remember).

Hope this helps a bit.

Regards,
Andreas
 
Cited references:
---------------------
Wirth, N., 1982 (1 ed.). Programming in Modula-2. Springer-Verlag: Berlin a.o, 176 pp.  PIM1
Wirth, N., 1983 (2 (corr.) ed.). Programming in Modula-2. Springer-Verlag: Berlin a.o, 176 pp.   PIM2
Wirth, N., 1984. Revisions and amendments to Modula-2. Internal report 59, Institut für Informatik ETHZ, Swiss Federal Institute of Technology, Zürich, Switzerland, 27-28 pp.
Wirth, N., 1985. Revisions and amendments to Modula-2. J. Pascal, Ada & Modula-2, 4(1): 25-28
Wirth, N., 1985 (3 (corr.) ed.). Programming in Modula-2. Springer-Verlag: Berlin a.o, 202 pp.   PIM3
Wirth, N., 1985. A fast and compact compiler for Modula-2. Internal Report 64, Institut für Informatik, ETH, Zürich, 1-22.
Gutknecht, J., 1985. Compilation of data structures: a new approach to efficient Modula-2 symbol files. Internal Report 64, Institut für Informatik, ETH, Zürich, 23-41 pp.
Wirth, N., 1988 (4 ed.). Programming in Modula-2. Springer: Berlin a.o., 180 pp.   PIM4

________________________________________________________________________

ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

address@hidden
www.sysecol.ethz.ch

+41 44 633-6090 phone
+41 44 633-1136 fax

             Make it as simple as possible, but distrust it!
________________________________________________________________________

Gaius Mulley wrote:

Hi,

I'm trying to track down in the various documentation whether equality
or inequality tests are allowed with structured types.  I'm assuming
not, I'll keep looking but the answer is not leaping out of the page
yet..  just wondering if anyone has read about this recently?

regards,
Gaius


_______________________________________________
gm2 mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gm2
  

--

________________________________________________________________________

 

andreas_fischlin.vcf
Description: Vcard