Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!psuvax1!husc6!m2c!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Of Globals Summary: And what about nested modules Message-ID: <251@smds.UUCP> Date: 23 Nov 90 07:34:05 GMT References: <242@smds.UUCP> Organization: SMDS Inc., Concord, MA Lines: 70 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". Module is one of those words which is used in a number of different senses in different contexts. I like "procedure" and "subroutine" because there is no doubt about what is meant. In any case the principle here seems to be that names within a procedure are strictly local unless explicitly imported or exported. Upon reflection I think that this is a good idea in a typeless language. If one doesn't do this there is a horrible vagueness about what a procedure is doing. > 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? Or does it mean that there can only be one external instance? > 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? If I understand this correctly you are working with a single namespace. Each module can add symbols to the name space dynamically; the names vanish when the module exits. This is sort of like the context idea. Does your export verb mean that symbols are passed down or up? Symbol table lookup may not be all that bad. Here is what I do in Lakota. Symbols are mapped into integers which are indices in a lookup table. When a raw symbol is processed it is hashed into an index into an array of list pointers which, in turn, point into the lookup table. The lookup table structure is something like this: struct symtab { struct symtab *hash_link; int hash_index; char *symtext; int length; int refcount; }; Procedures are memory resident in the form of arrays of integer lists. This means that the symbols in the procedure stay resident for the lifetime of the availability of the procedure whence the reference count stays positive. The result is that symbol table lookup is fast most of the time. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.