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

[Gaius Mulley]

Andreas Fischlin <address@hidden> writes:

> 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.


Hi Andreas,

many thanks for this well argued reply - I will hunt down the
references cited at the end.. - Definitely gm2 will not try and
implement equality of structured types.  In my earlier email I
hesitated when considering COMPLEX (which I imagine as a pseudo
structured type - on most architectures - although I could also be
wrong here!).  Anyway the problems with ARRAY [0..max] OF CHAR and
ARRAY OF CHAR and RECORDs as you point out cause the problem space to
explode..


> 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.

fortunately in the M2 ISO standard on p263 the section "6.9.3.2
Variable Parameter Compatibility" states very nearly the same:

"The formal type of a variable parameter shall be compatible with the
type of an actual variable if any of the following statements is true:

a)  The formal type is the address type and the actual type is any
pointer type.

b) The formal type is a system storage type, or a one-dimensional open
array of a system storage formal type, and is compatible with the
actual type as the type of a system storage parameter - see 6.9.3.3"

[6.9.3.3 describes issues surrounding SYSTEM.LOC, SYSTEM.BYTE and
SYSTEM.WORD]

"c) The formal type is an open array (other than a one-dimensional open
array of a system storage formal type), the actual type is an array
type, and the component type of the formal type is compatible, as the
formal type of a variable parameter, with the component type of the
actual type.

d)  The formal type is a single identified type that is identical to
the actual type."

although interestingly (unless opaque types are covered the statement
(a) - which I doubt) it disallows opaque and ADDRESS parameter
compatibility.  [This can be easily turned on/off via -fiso, -fpim2,
-fpim3 and -fpim4 options]

> To quote Niklaus Wirth "Standards are then agreed, if they have
> become irrelevant" (AFAI can remember).

very good :-)

> Hope this helps a bit.

yes indeed!  Many thanks..

regards,
Gaius


> 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