[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Fischlin
Subject: Re: [Gm2] equality, inequality tests and structured types
Date: Tue, 27 Jan 2009 16:26:59 +0100
User-agent: Thunderbird (Macintosh/20081209)

Dear Gaius,

We need to keep these issues separate, i.e. equality and inequality tests and coercability between pointers (ADDRESS) and variables of an opaque type. Therefore:


          x1,x2: MyOpaque;

     IF x1 = x2 THEN


     IF x1 <> x2 THEN

has not necessary anything to do with assignment compatibility. A construct like

          undefMyOpaque: MyOpaque; (read-only)

can serve to overcome this NIL incompatibility in the way I explained in my previous E-mail, given the (in)equality test is possible. That's the only place where I see some connection between the two issues.


Gaius Mulley wrote:
"Breeden, Thomas (tmb)" <address@hidden> writes:

Gaius Mulley wrote:

    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]

Andreas Fischlin <address@hidden> writes:

I'm no sure I quite get what you are saying here. I believe the
statement a) is quite appropriate. Indeed, I would expect this
compatibility to be given in any good Modula-2
implementation. However, I see no reference there to opaque
types. Do yo then mean what would be needed is another statement in
the ISO standard, one that would cover also compatibility questions
of opaque types in the case of variable proc parameters?
Gaius Mulley wrote:

oops - I was wrong (a) does imply opaque types - as I've found that the
ISO standard says:
"2. An opaque type may be redeclared as the address type, since the
address type is also a pointer type.
I spent some time this weekend pouring over the ISO document trying to determine if I could really allow a statement like this in a client   module importing an Opaque.

VAR  c :TheImportedOpaque;
c := NIL;

and I couldn't. The standard makes it clear that an Opaque type is
not a pointer type except within the Impl module which elaborates
the Opaque type as POINTER TO x or ADDRESS. It even states that
baldly, though I don't have the paragraph at hand.

Hi Tom,

do you have a reference for the above in the ISO standard?

Number 2. above is simply pointing out that ADDRESS is a pointer
type and can be used by the Opaque types IMPLEMENTATION module to
define it within its module only.

So, it looks to me that for strict ISO conformability, an Opaque
cannot be used in expressions or assignments or parameter
substitution w/r/t pointers and ADDRESS without a coercion, except
again, within the implementation module for that Opaque, as in
Andreas' example, except via CAST() for ISO.

In section Pointer Relational Operations we have

"Clarification - this part of ISO/IEC 10514 agrees with the third
edition of Programming in Modula-2, which allows the equality and
inequality operators to be applied to values of an opaque type."

It also says that:

"Annotations  Opaque types are indistinguishable from pointer types
with respect to the meaning function."


But I do wish that ISO had made an exception for assigning NIL to
Opaques, since without it you either have to initialize Opaques
either by providing an init proc for the client to call, or having
him use ovar := CAST(TheImportedOpaque, NIL), which might even be
dubious under ISO :)

my interpretation of the standard is that this is allowed:

FROM somemodule IMPORT OpaqueType ;

   o:  OpaqueType ;
   o := NIL
END ...


gm2 mailing list

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


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

             Make it as simple as possible, but distrust it!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]