Re: [Gm2] Re: ISO strangeness

[Izo]

Gaius Mulley wrote:

> "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
>  
Here is the question about how ISO Modula-2 compares types - name 
equality or content equality. If e.g. with C or PIM2 we redefine certain 
type we get at least warning (C) and error (PIM2), no matter if they are 
content equal. I am not sure, really how is the ISO M2 standard but I 
think that the M3 compares types by the content - thus assuring the safe 
types (safe pointers and safe storages contain the type information). I 
can see that Mr. Ledermann of GardensPoint overrides the previous 
definition of the type if the new definition is content equal. The code  
in GM's example is even a little simpler from Ledermann's:

DEF MOD a;

TYPE T;

DEF MOD b:

TYPE T = a.T;

DEF MOD c;

TYPE T = b.T;

IMP MOD c;

FROM a IMPORT T;


Contents - wise the all four definitions/declarations reference the same 
type - a.T. But that is what we know. What about compiler, what should 
it know ?

GPM2 does not complain. And I think that Mr. Moylan had cooperated with 
Mr. Ledermann and Moylan was standard member of ISO M2 (whatever WG it 
was) commitee. I am not sure for the StonyBrook or XDS - I can not test 
them right now. Maybe the example is ready for Peter Moylan and Norman 
Black on the comp.lang.modula2. Make them wake up a little - small 
amount of posts there lately, really !

Regards, Iztok

Do not reply to Reply-To address. Use iztok dot kobal at iskrasistemi 
dot si  instead if you answer directly.

>  
>
> > > 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
> >    
>
> _______________________________________________
> gm2 mailing list
> address@hidden
> http://floppsie.comp.glam.ac.uk/mailman/listinfo/gm2
>
> .
>
>