[M3devel] scope/resolution of foo in interface foo = foo(bar)

[Rodney M. Bates]

Mika Nystrom wrote:
> Jay K writes:
> ...
>> import foo=3B
>> import foo(bar)=3B
>> import foo(bar) as foobar=3B
>> import foo(bar).T as fooT=3B
> 
> Modula-3 doesn't work like that.
> 
> You have to say
> 
> INTERFACE X = G(Y) ...
> 
> IMPORT X
> 
> You can't import "G(Y)" directly.  Saves having to worry too much about
> name mangling.
> 
> Having a generic interface and a normal one with the same name is a common
> pattern for me, at least.
> 
> You often have a single supertype and then many subtypes that are related
> to that supertype by being extended with, say, a field of an arbitrary type.
> 
> Then you get...
> 
> INTERFACE Stuff; TYPE T ... END Stuff.
> 
> GENERIC INTERFACE Stuff(Specializing);
> IMPORT Stuff;
> TYPE T = Stuff.T OBJECT special : Specializing.T END;
> END Stuff.
> 
> INTERFACE SpecialStuff = Stuff(Special)
> 
> Very convenient to use the same name at the top level, I think.
> 
>     Mika

Yuck! I hate this.  One of the things I really hate about Java and C++ is
having many different ways in which a reference to an identifier is looked
up, depending on the context of the reference.  This is one of the big ways
a language gets obscenely overcomplicated without providing any useful benefits.

One of Modula-3's strengths is that when an unqualified identifier is
referenced, it is always looked up according to the same rules, no matter
what kind of thing it is.  Only afterwards are semantic rules applied like,
e.g., the context requires a type but the identifier is a constant.

Except for this example, which I had missed up until now.  IMPORT Stuff
(and also EXPORTS Stuff) looks up Stuff as a global name in a different
way from INTERFACE SpecialStuff = Stuff(Special).  Unfortunately, the language
fails to address this at all in 2.5.5, and the implementation managed to
get away with violating the principle.  So now we have a bit of a slip into
the evil world of junk programming languages.

As for its being convenient, it may save a bit of effort during the initial
coding phase, by not requiring you to think up distinct names, but it is a
cruel and inhuman punishment to inflict on the miserable but innocent wretch who
has to maintain  your code later.  And in just case someone needs to be reminded,
coding is short.  Maintenance is long, sometimes almost forever.

We really should amend the language to say that ordinary and generic interfaces
combined must all have distinct global names.  Likewise for ordinary and
generic modules.

>