Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!princeton!udel!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!nuchat!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.misc
Subject: Re: Request For Comment About Handling Of Globals
Message-ID: <Y+=69_G@xds13.ferranti.com>
Date: 16 Nov 90 18:54:55 GMT
References: <242@smds.UUCP>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 33

I have been facing a similar problem in a series of extension packages
for TCL. The technique used in modula, where every "global" object actually
has module scope and must be explicitly imported into another module seems
attractive, but I've not had occasion to use Modula much to see how well
it handles in practice (basically, different Modula compilers all seem to
have unique and contradictory runtime libraries... so portable modula code
becomes pretty damn hard to write).

I've been thinging of doing something like this (in TCL):

	module modulename {
		import othermodule symbol...
		...
		export symbol...
	}

Because of compatibility considerations, all existing symbols are assumed
to be in a root module "tcl" which is imported implicitly. But this brings
up the question of what this means:

	module modulename {
		module newmodule {
			...
		}
	}

My first reaction is that in this submodule all symbols in the outer module
are defined. This means that the root module is just another example of a
module. The downside is that symbol table lookups could become quite hairy,
and because this is an interpreted language (though I've got ideas for
compiled TCL) this would negatively impact runtime efficiency.

Input?
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com