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

[Andreas Fischlin]

Dear Iztok,

Iztok Kobal wrote:

I would agree with Thomas.

And Gaius, we have already had some talk about opaque types
implementation some time ago and I remember sending you some samples of
opaque types usage in ISO library code from StonyBrook M2 and
GardensPoint M2. Please consider also theese since I would suppose they
had done their business according to standard.
  

Not necessarily.

I do not really remember what was all about back then. Yet, the outcome
was that the "problem" with opaque types is that their storage size is
unknown in compile time for other modules since their implementation is
hidden so some kind of generalization is needed - maybe considering them
as being of size ADDRESS. And second, by no means can they be compared
between each other since each and every of them represents different type.
  

That's not quite correct. We are talking here only about (in)equality tests between two opaque variables of the same type. Of course is there any comparison among different opaque types completely out of question. Would be against all the fundamental type checking philosophy of Modula-2. Moreover, comparing opaque variables has nothing to do with the hidden objects they represent. Therfore also nothing with the memory allocation needs of those hidden objects. In an OOP context I'd say, the comparison serves only the purpose to check whether the instantiation of the hidden object is the same or not.

As for COMPLEX, I would consider it as GM2 extension, atomic type, so
direct comparission could be allowed between two variables of COMPLEX,
including possibility to pass and return them to/from procedures. The
implementation of type conversions via VAL() is yet to be considered - I
suppose you already had implemented some kind of solution.
  

All variables of type COMPLEX, since of the same type, are again in principle compatible. Whether ISO calls for (in)equality tests is not clear to me, since I am not familiar enough with ISO Modula-2. It would be logical but I could also imagine implementation restrictions, since comparison of COMPLEX is more than just the traditional, one register based equality test. But sure it could be done.

Regards,
Andreas
 

Regards, Iztok

Breeden, Thomas (tmb) wrote:
  

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;
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 :)

regards,

Tom



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

  
    

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

 

andreas_fischlin.vcf
Description: Vcard