Scope of imported names

[Wolfgang Lux]

Hello!

> Well, it's not that simple currently. Name clashes are only illegal if they
> lead to unresolvable references. Thus if we have

Intricate, indeed. I didn't expect to be able to define a function 
which I cannot reference with its unqualified name.

> > > What I'm driving at is this: I propose that top level bindings shadow
> > > imported names and that qualified names can not be used to refer to
> > > declarations in the same module. 
> > 
> > The second part is going to conflict with the revised report which relies 
> > on the qualified names of entities in order to specify which entities export
> ed 
> > from module M (module M) where { ... }
> 
> That's right (this refers to section 5.2, fifth numbered item). What is
> the rationale behind requiring the qualified name to be visible also?

If I remember right (I didn't track this down in the mail archives), 
the reason was to clarify the meaning of an as clause on an import. 
I.e., the export list of

  module M(module N)
    import N as P

should be empty, while 

  module M(module P)
    import N as P

exports all of the entities exported from module N.

> > who prefers to forbid shadowing of imported names :-)
> 
> Even by nested bindings?

No. Otherwise you would probably ask me why I don't want to forbid 
shadowing of global names by local ones. However, I still don't 
like the proposal because it allows to shadow imported definitions 
without noticing. IMHO this is less a problem for local definitions 
inside a function (which is rarely more than few lines long and thus 
more easily comprehensible) than for a whole module.

Wolfgang


--
Wolfgang Lux				  Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik	    FAX: +49-251-83-38259
Universitaet Muenster		      Email: wlux@uni-muenster.de