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

[Gaius Mulley]

Andreas Fischlin <address@hidden> writes:

> Hi Gaius,
>
> Gaius Mulley wrote:
>
> snip
>
>     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.
>
>
>
> snip
>
>     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]
>
>
>
> 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?

Hi Andreas,

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.

CHANGE - In the third edition of Programming in Modula-2, opaque types
must be declared as pointer types.  This part of ISO/IEC 10514 allows
an opaque type to be declared as another opaque type, since that other
opaque type must directly or indirectly be implemented as a pointer
type.

CLARIFICATION 1 - An opaque type cannot be declared as a scalar type."

ISO/IEC 10514. P34

However I think it would have been helpful had the ISO standard
explicitly mentioned opaque types above.

> I have a pragmatic view here: I believe it is best to expect from a
> Modula-2 implementation to use type SYSTEM.ADDRESS for implementing
> opaque types. Then a coercion of the following kind (emphasized in
> red) is possible for any opaque type:
>
> In high-level (user visible module) definition module:
>
>   TYPE
>     Matrix;
>
>    
> In the implementation of the high-level (user visible module):
>
>   PROCEDURE DeclMatrix( VAR m: Matrix;
>                         nRows, nCols: INTEGER;
>                         name : ARRAY OF CHAR   );
>     VAR theMat: MLBase.Matrix;
>   BEGIN
>     theMat := MLBase.Matrix( m );
>     MLBase.DeclMatrix( theMat, nRows, nCols, name );
>     m := Matrix( theMat );
>   END DeclMatrix;
>  
>  
> In low-level (internal) definition module:       
>      
>   TYPE
>     Matrix = POINTER TO MatrixData; (* implementation of Matrices.Matrix *)
>     MatrixData = RECORD
>       ...
>      
>   PROCEDURE DeclMatrix( VAR m: Matrix;
>                         nRows, nCols: INTEGER;
>                         name : ARRAY OF CHAR   );
>   BEGIN                       
>       ...
>       Allocate( m, SIZE(MatrixData) );
>
>
> BTW, we use above technique in RAMES quite lots and I argue such constructs
> should be possible in any powerful Modula-2 implementation.

Yes gm2 should handle this..
here is a snippet from gm2/gm2-libs-iso/IOchan.mod (IOChan.ChanId is
opaque)

PROCEDURE MakeChan (did: DeviceId; VAR cid: IOChan.ChanId) ;
BEGIN
   checkValidDevice(did) ;
   cid := IOChan.ChanId(RTio.InitChanId()) ;
   IF cid=NIL
   THEN
      cid := IOChan.InvalidChan()
   ELSE
      WITH did^ DO
         RTentity.PutKey(cids, cid, ORD(allocated))
      END ;
      RTio.SetDeviceId(cid, did) ;
      RTio.SetDevicePtr(cid, InitDtp(did, cid))
   END
END MakeChan ;

regards,
Gaius