🚀 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.

Would it work just as well to say
class Foo {
#include "something.h"
}

since classes and everything else (?) can -- eventually -- be nested inside
classes.
>
>The only problem I can see with it concerns the issue of binary-only
>library distribution, which, it has already been noted, is problematic
>anyway.  It is not hard to imagine linker extensions that could fix
>this, but I gather that is considered an undesirable thing to do.
>

We already (pre-C++) have namespace problems in libraries.  Two functions
in different libraries can have the same name and the ambiguity is
resolved by the order in which the libraries are linked.  The same thing in
the C++ case will take care of all situations except where the programmer
actually uses a global name which is in both libraries but wants the one from
the library later in the compile command line.  This is likely to be much
more common in C++ than it was in C I think.  The linker extension to 
accommodate this would be straightforward.
	1) Be able to associate a scope identifier (e.g. MyLib:: ) with
	a library either in a program or on the command line.
	2) Have the linker defer any references beginning with such scope
	identifiers until the library associated with that scope id.
	3) Global names without scope ids associated with libraries would
	be resolved as before -- giving backwards compatibility.
Still perhaps more than anyone wants to do.  However if anyone ever changes
the linker for other reasons...

David R. Cok
Eastman Kodak Company -- Imaging Science Lab
cok@Kodak.COM