🚀 go-pugleaf

In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>
>To see if we can get some discussion going on the matter, let me
>sketch a simple proposal.  Suppose we were to introduce a keyword
>"module" with a simple syntax:
>
>   module Foo {
>     // ... declarations
>   }
>
>The intent here is that the declarations within the braces have
>exactly the same form as those normally found at top level, so that
>one can write things like
>
>   module Foo {
>   #include "something.h"
>   }
>
>where the author of the header file need not have done anything
>special to make such usage possible.
>
Let me refer to this as the "standard proposal" for no better reason than
that I have proposed the exact same syntax elsewhere. 

One could embellish this to give the module private and public parts,
overcoming the wretched "static/extern" syntax. 

But there are some significant problems with name space control. While you
now can disambiguate a name conflict in the source file

	module A { ... int f() ... }
	module B { ... int f() ... }

on the link level, there are still two global functions f() which cannot
be distinguished. Sure, the implementation of the f()'s could also be
contained in module A { ... } and module B { ... } wrappers, but that
rather negates the module A { #include "..." } trick. And it doesn't
protect against the problem of two module designers assigning the same
module name. 

Also, one may well argue that 

	module A { /* global data and functions */ }

is no different from 

	class A { /* the same data and functions */ }
	main() { A anInstance; /* ... */ }

so the feature is unnecessary. 

Does anyone have any idea how to overcome the problem of two classes/
global functions having the same name using a renaming syntax like in
Eiffel? I can see how this works in the compilation stage, but I still
don't understand how one can do the link step with a standard linker. 

Cay