Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!strath-cs!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Of Globals Message-ID: Date: 27 Nov 90 15:34:08 GMT References: <242@smds.UUCP> <252@smds.UUCP> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 116 Nntp-Posting-Host: odin In-reply-to: rh@smds.UUCP's message of 23 Nov 90 07:45:51 GMT On 23 Nov 90 07:45:51 GMT, rh@smds.UUCP (Richard Harter) said: rh> In article , pcg@cs.aber.ac.uk rh> (Piercarlo Grandi) writes: [ ... on the issue of scoping rules ... ] pcg> Oh yes. And I have decided to come out of the closet with a profound and pcg> utterly revolutionary secret that I have been holding in my conscience pcg> for so many years. Alas, no more. I have to pull this weight off my pcg> chest (I am also pulling your leg a bit here :->). rh> Pull on the right one, please. The left one is already 47 feet rh> long. Ohhhh. I can imagine how badly you must limp (unless you keep it coiled like a flamingo :->). Hazards of reading News... rh> Piercarlo introduces the interesting notion of inverting the rh> operation of scoping. [ ... ] I am going to have to think about rh> this one. I would be enchanted to see some further development of rh> this idea. Ah, a customer! Welcome sir, here we have a full range of interesting reasons for which top down scope rules are better than inside outside ones. Which one would you like to see first? Would you mind "reuse" to start? If you use top down scope rules you have a tree (picture it as in traditional CS fashion with the root at the top, like a genealogical tree) of closures. Each piece of code sees only the closure in whose context it executes and its descendants. This means that modules are perfectly reusable; the same subtree can be linked in transparently in many places in the overall tree (which becomes a DAG, or even a general directed graph, actually). Consider the alternative with inside outside; modules that use globals cannot be reused as easily. In particular, code that uses globals to fake generators (subroutines that need to remember state between invocations) is obnoxiously bad to reuse. WIth top down scoping, two subtrees that need to communicate, instead of being nested in the same scope, can just share subtrees of their environment. In a top down scoping language a library is just a subtree which contains the bindings for all the library entities; it is easy to reuse the library everywhere without bothering about possible name clashes at the global level (try to do that in C++ with three libraries which both define an Object class!). There is *no* global level. This does not mean that the library or any functions in it needs to be stateless, because its naming subtree can well contain bindings for persistent entities -- indeed all the subroutines in the library will be lumps of code statically bound to their identifiers. rh> The idea is, of course, utterly unsettling to those of us rh> for whom the traditional rules are engrained. Actually some of top down scope rules is not entirely new. Consider Ada or many other modular languages; modules nest BOTH inside out and top down; you can refer to the names of the enclosing module, but also the enclosing module can refer to the entities in the enclosed ones (dot notation). I maintain that only the latter should be allowed. If the enclosing module wants to "show" some names to an enclosed module, this should be done by the enclosing module appending the relevant naming subtree under the enclosed one, not the latter importing those names explicitly (and thus making itself dependent on where it is linked in the environment tree). This is the really different aspect of top-down naming. It also implies that the modules need not be textually nested, and this means that each module can be compiled on its own, and that shaping the required naming substrees for a module is the responsibility of the upper (but not really enclosing) modules. In other words envirionment tree shaping is totoally decoupled from module implementations, allowing mix and match between module interfaces and implementations, in a transparent way. If you want another example in which things may be familiar, consider a UNIX like filesystem tree in which each directory contains a single module, which is linked against modules in lower directories, and where you can use (symbolic) links to share subtrees (or even, and this may make sense at times, loops in the naming structure). Unfortunately current linkers enforce a linear name resolution system, so that if you use a current linker you must produce a preorder traversal of the tree of module directories, and this may greatly reduce the value of the tree, because it makes for conflicts and ambiguities. The above arrangement is often used in actual C programming practice, because C mercifully essentially disallows nested (inside outside) scoping (in a C source file the static entities are the module's closure, the extern references are the roots of lower subtrees and the extern definitions are the leaves of upper subtrees). What I am saying is that this (incomplete) arrangement is the one that one wants to use, not just at the intermodule level, but also thruout the language. I can easily see possible implementations; they become easy to design once one gets into the habit of visualizing environment trees (graphs, actually), whether they are linearized on a stack or not, e.g. see Baker's landmark paper on shallow binding in Lisp, CACM 1.5. The fact that most algorithmic languages linearize both the environment tree and the control tree on a stack has made most people regrettably assume that it is the only possible way, blinding them to things like closures, partial application, generators, i.e. fully general (and orthogonal!) environment and control graph shapes. As soon as you picture the environment tree you start to realize that searching for names upwards is madness, because it makes subtrees context dependent, and kills reuse. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk