[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Breeden, Thomas (tmb)
Subject: RE: [Gm2] equality, inequality tests and structured types
Date: Sun, 25 Jan 2009 21:02:28 -0500

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



reply via email to

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