Proposal to add modules to C

[Chris Torek]

It seems to me that the main (if not only) reason to avoid using global
variables (as opposed to ``module-level'' variables, i.e., accessible
to foo.c and bar.c but not baz.c) is to avoid name collisions.  If the
variable makes sense as a statically-allocated unit, why would you care
whether baz.c can get at it, unless you want to ensure that no accidental
changes or references are made?  [I will mention functions later.]

Anyway, assuming that I'm not already way off base, this can be done
quite easily in C as it stands right now, by using long names (let's not
start *that* again: I only need long internals for this argument, and
the current ANSI draft has 31 character internal names) and structures.

For example, if files foo1 and foo2 are to share access to a data
structure, you might create a corresponding foo.h file:

	struct foodata {		/* private globals for foo */
		int	fd_int;
		double	fd_fp;
		/* and more */
	};

	extern struct foodata foodata;	/* declared in fooglob.c */

	/* Now we hide the fact that they are really in a struct */
	#define foo_int foodata.fd_int
	#define foo_fp	foodata.fd_fp

Within foo1 and foo2, these variables appear to be globals.  To anyone
who does not include foo.h, there is only one name to worry about (and
it need not make much sense; indeed you can hide the ugly 6-character
externals this way---#define's are internal names, and therefore have
at least 31 significant characters).

This admittedly leaves function names out in the cold....  I'd suggest
using function pointers inside foodata, and initialization routines, but
someone would gripe about run time.  (Personally, I'll just use my long
identifier names.)  Well, if you want more, try Mesa.  It's got more
modules (and more strict type checking) than any Unix hacker would know
what to do with....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland