Scoping additions

I'm puzzled by the meaning of the rule for subelements
of functions. Presumably you don't want the body of a function that is a
public member of a class to be usable by anyone who can call the function...
or do you?

Also, the public member scope rule is ambiguous for inherited members. If an
element is a public member of class C, and inherited as a public
member in the subclass D, is its scope the scope of C or that of D? This is
important if C is a "standalone" class (superelement = null) and D is a
private member class of some other class E. I think what you want is to make
rules like "scope = null if super(e) = null" since superelements are
unambiguous; but I could be wrong.

In any case, the "scope" function is named confusingly.
scope(e) is "the entity or entities that e is in the scoping domain of". So the
elements of scope(e) are, as you say, always going to be higher in the
hierarchy than e. It would seem more natural to define scope(e) as a big set
of "things in the scope of e" in such a way that you can state the semantic
rule as "forall e in E, forall f in elements-used(e), f in scope(e)". That
definition would probably be messy, though.

Alternatively, you could define the function as "scoping_domains" instead of
"scope"; then your rule consists of the statement "for every element f used
by e, one of the scoping domains of f must be a (super*)element of e", which
sounds intuitively right to me. Then \emptyset corresponds to the global
scoping domain, you have a private scoping domain for each capsule's private members, etc. Sorta like group permissions in UNIX.

And the above brings up a terminology issue: I think we need a term like
"(super*)element of e" that means "in e's chain of superelements," analogous
to "ancestor" generalizing "parent".

The basic idea looks right, though-- although a clearer view of how scoping fits into the rest of the semantics will have to await the coming of algorithmic semantics. I think your questions about "what does this unqualified name mean" and "do subclass overrides hide superclass elements" are actually going to be less important than one might think,
because of representation-independence and fullname uniqueness-- the
analogous questions in existing languages, to the extent I understand them,
are really text-syntax questions as much as real semantic issues.