🚀 go-pugleaf

On 23 Nov 90 07:45:51 GMT, rh@smds.UUCP (Richard Harter) said:

rh> In article <PCG.90Nov16161830@odin.cs.aber.ac.uk>, 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