gm2
[Top][All Lists]
Advanced

[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:18:25 +0100
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

Dear Thomas,

Thanks for your efforts in looking up those points in the ISO documentation.

Breeden, Thomas (tmb) wrote:
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;
BEGIN
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.

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.

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 :)
  
Sorry, I am of the opinion that there is no need to relax any of these restrictions. AFAIK it would cause a lot of havoc and little would really be gained. The only drawback I see from these constraints are constructs like this one (as an illustrative example from RAMSES):

http://se-server.ethz.ch/RAMSES/Objects/MW/SimGraphUtils.html#180_2

TYPE
    Curve;

  VAR
      nonexistent: Curve;  (* read only! *)

It would be preferable to have a real constant declaration for such a read only variable.

On more general terms, what I recommend to any implementer though, is to make sure that casting of the kind in the implementation of above code exerpt

    nonexistent := Curve(NIL);

or in ISO

    nonexistent := CAST(Curve, NIL);

will work correctly. This would allow for statements such as

    VAR
        myCurve: Curve;

    IF myCurve <> nonexistent THEN
    ...

in clients code using these facilities and many more constructs actually being crucial for writing useful code (as I described in my previous E-mail). Hope you can agree to these arguments?

Regards,
Andreas
 
regards,

Tom



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

--
________________________________________________________________________
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!
________________________________________________________________________
 

reply via email to

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