🚀 go-pugleaf

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