Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!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: 16 Nov 90 16:18:30 GMT References: <242@smds.UUCP> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 69 Nntp-Posting-Host: odin In-reply-to: rh@smds.UUCP's message of 15 Nov 90 08:43:27 GMT Posting-Front-End: GNU Emacs 18.55.4 of Thu Nov 23 1989 on athene (berkeley-unix) On 15 Nov 90 08:43:27 GMT, rh@smds.UUCP (Richard Harter) said: [ ... on the issue of scoping rules ... ] rh> What I am looking for is ideas. What are some of the approaches that rh> can be used, and what are the pros and cons of these approaches. rh> Actually what I am fishing for is an approach that combines elegance rh> and simplicity with the constraint that it should not be confusing rh> or daunting to a naive user. It seems to me that this is a worthy rh> topic for this group. Oh yes. And I have decided to come out of the closet with a profound and utterly revolutionary secret that I have been holding in my conscience for so many years. Alas, no more. I have to pull this weight off my chest (I am also pulling your leg a bit here :->). Traditional Algol inspired scope rules are completely wrong. Most of the evils and difficulties in modularization and reuse are because of this catastrophic mistake. This is that lower level modules can be made to depend on the details of higher level ones (e.g. global variables) which is crazy. In other words, the mistake is that currently scopes nest in the wrong direction; the right idea is that an higher level entity should be able to see the names in a lower level one, not viceversa. In other words, the right model is not contours and visibility from inside to outside, but a tree and visibility from top to bottom. It must also be possible for an higher level module to manipulate a lower level one's name table. For example argument passing should be defined in these terms; but also this must include the ability to append naming subtrees under a lower level entity. In other words a module should be able to manipulate instances of lower level modules both as to the values that names assume in that module and to the shape of the naming tree beneath it. Modules should be able to be parametric with respect to non only the values of their names, but also those beneath them. Also, it must be possible to create several instances of a module, and bind names and subtrees differently in each instantiation (and this subsumes generators, closures, generics, overloading, polymorphism, ...). There is one possible objection to top bottom (instead of inside outside) scoping and it is that a module can then access unitialized variables of lower lever modules. Well, if it correct, it will not -- it is an error to do so. Please note that top bottom is *not* exactly the reverse of inside outside! A top module can have many bottom modules at the same level of nesting, but an inside module can have only one outside modules at the same level of nesting (multiple inheritance is a poor attempt to get around this). I do believe that this view of scoping is as "powerful" as the other one and is the most elegant and flexible one -- and its has obvious and large modularity advantages. In particular it subsumes inheritance etc... Similar research? That I know of, only BETA, which has a notion of 'pattern' with very similar properties, even if I don't think that the notion that their scopes nest top to bottom is explicit. Disclaimer: the above is an atrocious presentation of some very unusual idea -- plase make allowance for the extremely elliptical style of presentation... -- 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