Re: [Gm2] Re: ISO strangeness

[Gaius Mulley]

"Peter P. Eiserloh" writes:

> Hello Gaius,
> 
> Yes, this is valid Modula-2.  Not only with ISO M2, but also with PIM3
> (which I have).  The type [b] is an opaque type, which most compilers
> implement as a pointer.  What it points to has to be defined later in
> an implementation module.  In Modula-3 this is called revealing the
> type.
> 
> This facility exists to allow abstract types, and hiding of
> implementation details, while still maintaining type safety.
> 
> 
> To quote from PIM3 (page 169)
> 
>    Definition modules imply the use of qualified export.  Type
>    definitions may consist of the full specification of the type (in
>    this case its export is said to be transparent), or they may consist
>    of the type identifier only.  In this case the full specification
>    must appear in the corresponding implementation module, and its export
>    is said to be _opaque_.  The type is known in its importing modules by
>    its name only, and all its properties are hidden.  Therefore, procedures
>    operating on operands of this type, and in particular operating on
>    its components, must bedefined in the same implementation module
>    which hides the type's properties.  Opaque export is restricted to
>    pointers.  Assignment and test for equality are applicable to all
>    opaque types.
> 
> Wirth also has some examples starting on page 90 TableHandler, whose
> definiton module defines an opaque type [Table].  Later on page 93, the
> implementation module defines a TreePtr which is a pointer to a record,
> and then the type definition:
> 
>     Table = TreePtr;
> 
> 
> In sum, yes the facility you described is not only allowed but it use is
> encouraged.  You simply used a bad choice (SYSTEM.ADDRESS) for the type
> of pointer to which b.i was defined.
> 
> 
> Peter P. Eiserloh
> 

Hi Peter,

thanks for the reply! I agree with your opaque description and that it
is PIM [234] and ISO compatible. Maybe I didn't ask the correct
question :-) my query was with module `a' rather than module `b'.

In the definition module of `a' we declare and define a TYPE i to be
the same as b.i and then in the implementation module we import an
opaque type 'i' from module 'b'. I'd have thought that a compiler
would complain when it was compiling the implementation module 'a'
because 'i' was also declared in the definition module.

In effect I thought the compiler starts to populate the environment
for module 'a' with those items defined and imported by the definition
module for 'a' and the continues to populate the environment with
those objects defined and imported in the implementation module 'a'.
My query is whether the compiler could complain about the duplicate 'i'.

Gaius

> > DEFINITION MODULE a;
> > IMPORT b;
> > TYPE
> >    i = b.i ;
> > END a.
> > 
> > IMPLEMENTATION MODULE a;
> > FROM b IMPORT i;
> > END a.
> > 
> > DEFINITION MODULE b;
> > TYPE
> >    i;
> > END b.
> > 
> > IMPLEMENTATION MODULE b;
> > IMPORT SYSTEM;
> > TYPE
> >    i = SYSTEM.ADDRESS;
> > END b.
> > 
> > I'd have thought that when compiling module, a, an error should be
> > generated as the object, i, is being redeclared in the IMPLEMENTATION
> > MODULE. Can anyone verify:
> > 
> >  +  that this is legal in ISO M2
> >  +  and out of interest which compilers allow this
> > 
> > Thanks Gaius
> > 
> 
> _______________________________________________
> gm2 mailing list
> address@hidden
> http://floppsie.comp.glam.ac.uk/mailman/listinfo/gm2