Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!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: Date: 24 Nov 90 15:49:21 GMT References: <242@smds.UUCP> <251@smds.UUCP> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 29 In article <251@smds.UUCP> rh@smds.UUCP (Richard Harter) writes: > In article , peter@ficc.ferranti.com (Peter da Silva) writes: > > I have been facing a similar problem in a series of extension packages > > for TCL... I've been thinging of doing something like this (in TCL): > > module modulename { > > import othermodule symbol... > > ... > > export symbol... > > } > So far, so good. However I don't know how you are using the word "module". Good point. "Module" here refers to a collection of symbols with a common scope. No control flow commonality is implied. Perhaps I should say "package"? Or borrow from forth and call it a "vocabulary". > > Because of compatibility considerations, all existing symbols are assumed > > to be in a root module "tcl" which is imported implicitly. > Ouch. Does this mean that there can only be one instance of a symbol? No, it means that symbols already defined in existing TCL code (such as proc or ErrorInfo) are in the root vocabulary. > If I understand this correctly you are working with a single namespace. Existing TCL has a single namespace. I'm extending this to a group of namespaces. Control flow doesn't come into it. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com