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