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

[Iztok Kobal]

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.

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.

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.

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