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: Gaius Mulley
Subject: Re: [Gm2] equality, inequality tests and structured types
Date: Tue, 27 Jan 2009 14:07:00 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

"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;
> 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.

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 6.8.2.7.5 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."

P215

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

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

regards,
Gaius




reply via email to

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