Re: [Gm2] GM2 Bug no. 2

[Gaius Mulley]

Iztok Kobal <address@hidden> writes:

> GM2 - latest CVS
> 
> #>gm2 -c -Wiso -save-temps -g3 -O3 -gstabs+ -I. B.mod
> B.mod:6:the following unknown symbols in module B were unresolved
> B.mod:5:unknown symbol (a)
> 
> #>gm2 -c -Wiso -save-temps -g3 -O3 -gstabs+ -I. B1.mod
> B1.mod:6:symbol (T) is already declared in this scope, use a different
> name or remove the declaration
> B.def:6:and symbol (T) is also declared here
> 
> Well, one of both or both should compile !
> 
> I would vote for the B.mod ! Seems correct enough to me.
> 
> I am not sure about the regularity of the overriding the T in B1.mod
> but taking in consideration hiding and lolality concept of the
> Modula-2 the global scope of the .mod is not so much global as the
> globality of the scope of the .def. So the B1.mod should compile
> too. Or I am wrong ?

Hi Iztok and fellow M2 subscribers!

I've been examining the ISO standard w.r.t this issue and have
summarised my understanding in the file gm2/gm2.texi. Below is
the relevant portion of the file, I'd value input on whether you
think this understanding is correct, before I modify gm2 :-)

Thanks Gaius

----- cut here ----- cut here ----- cut here ----- cut here 


@section Scope rules

This section describes my understanding of the Modula-2 scope rules
with respect to enumerated types.  If they are incorrect please
correct me by email @email{gaius@@glam.ac.uk}. They also serve to
document the behaviour of GNU Modula-2 in these cirumstances.

In GNU Modula-2 the syntax for a type declaration is defined as:

@example
TypeDeclaration := Ident "=" Type =:

Type :=  SimpleType | ArrayType
          | RecordType          
          | SetType             
          | PointerType         
          | ProcedureType
      =:                                                                   
                                                                           
SimpleType := Qualident | Enumeration | SubrangeType =:

@end example

If the @code{TypeDeclaration} rule is satisfied by
@code{SimpleType} and @code{Qualident} ie:

@example
TYPE
   foo = bar ;
@end example

then @code{foo} is said to be equivalent to @code{bar}. Thus
variables, parameters and record fields declared with either type will
be compatible with each other.

If, however, the @code{TypeDeclaration} rule is satisfied by any
alternative clause @code{ArrayType}, @code{RecordType},
@code{SetType}, @code{PointerType}, @code{ProcedureType},
@code{Enumeration} or @code{SubrangeType} then in these cases a new
type is created which is distinct from all other types.  It will be
incompatible with all other user defined types.

It also has furthur consequences in that if bar was defined as an
enumerated type and foo is imported by another module then the
enumerated values are also visible in this module.

Consider the following modules:

@example
DEFINITION MODULE impc ;

TYPE
   C = (red, blue, green) ;

END impc.
@end example

@example
DEFINITION MODULE impb ;

IMPORT impc ;

TYPE
   C = impc.C ;

END impb.
@end example

@example
MODULE impa ;

FROM impb IMPORT C ;

VAR
   a: C ;
BEGIN
   a := red
END impa.
@end example

Here we see that the type @code{C} defined in module @code{impb} is
equivalent to the type @code{C} in module @code{impc}. Module
@code{impa} imports the type @code{C} from module @code{impb}
and at that point the enumeration values @code{red, blue, green}
(declared in module @code{impc}) are also visible.

The ISO Standand (p.41) in section 6.1.8 Import Lists states:

``Following the module heading, a module may have a sequence of import
lists. An import list includes a list of the identifiers that are to
be explicitly imported into the module. Explicit import of an
enumeration type identifier implicitly imports the enumeration
constant identifiers of the enumeration type.

Imported identifiers are introduced into the module, thus extending
their scope, but they have a defining occurrence that appears elsewhere.

Every kind of module may include a sequence of import lists, whether it
is a program module, a definition module, an implementation module or
a local module. In the case of any other kind of module, the imported
identifiers may be used in the block of the module.''

These statements confirm that the previous example is legal. But it
prompts the question, what about implicit imports othersise known
as qualified references.

In section 6.10 Implicit Import and Export of the ISO Modula-2 standard
it says:

``The set of identifiers that is imported or exported if an identifier
is explicitly imported or exported is called the (import and export)
closure of that identifier. Normally, the closure includes only the
explicitly imported or exported identifier. However, in the case
of the explicit import or export of an identifier of an enumeration
type, the closure also includes the identifiers of the values of that
type.

Implicit export applies to the identifiers that are exported (qualified)
from separate modules, by virtue of their being the subject of a
definition module, as well as to export from a local module that
uses an export list.''

Clearly this means that the following is legal:

@example
MODULE impd ;

IMPORT impc ;

VAR
   a: impc.C ;
BEGIN
   a := impc.red
END impd.
@end example

It also means that the following code is legal:

@example
MODULE impe ;

IMPORT impb ;

VAR
   a: impb.C ;
BEGIN
   a := impb.red
END impe.
@end example

And also this code is legal:

@example
MODULE impf ;

FROM impb IMPORT C ;

VAR
   a: C ;
BEGIN
   a := red
END impf.
@end example

And also that this code is legal:

@example
DEFINITION MODULE impg ;

IMPORT impc;

TYPE
   C = impc.C ;

END impg.
@end example

@example
IMPLEMENTATION MODULE impg ;

VAR
   t: C ;
BEGIN
   t := red
END impg.
@end example