[Grace-core] Name resolution

[Michael Homer]

On Mon, Mar 23, 2015 at 7:16 PM, Andrew P. Black
<andrew.p.black at gmail.com> wrote:
> In an attempt to ground the discussion, let me try to explain what I think
> the problem is that Michael’s email is starting to address.
>
> Here is a (slightly edited) snippet from the collections prelude — I find
> real examples more instructive than "a, b, c" examples.
>
>
> class collection.trait<T> {
>     // requires withAll(elts:Collection<T>) -> Collection<T>
>     method with(*a:T) -> Unknown { self.withAll(a) }
>     method empty -> Unknown { self.with() }
> }
>
> factory method list<T> {
>     inherits collection.trait<T>
>
>     method withAll(a:Collection<T>) -> List<T> { … }
>
> }
>
>
>
> This looks fine at first sight.  list inherits from collection.trait, which
> seems to be lexically bound, and thus “definitively static”.   The compiler
> knows what it means, and all is well.
>
> But wait.  Suppose that gUnit inherits from list:
>
> class testSuite.forMethod(methodName) {
> inherits list<Test>
> …
> method collection { … }
> …
> }
>
> Now, what does “collection.trait” mean in the collections prelude (line 8 of
> the first snippet)?   According to the current language rules, ‘collection’
> is ambiguous: it is defined both on the lexical chain (as a class) and on
> the inheritance chain, because a subclass of list defines it.  So the
> compiler must reject the definition of list, and require the programmer to
> write either outer.collection.trait or self.collection.trait.  (The latter,
> of course, fails the “definitively static” test).
>
> The problem is that the compiler can hardly reject “inherits
> collection.trait” under these circumstances, because that would mean
> rejecting almost all inheritance.
>
> The solution that I suggested during the teleconference last week was to
> record, in an "heir’s specification” for list, the fact that the code in
> list assumes that the name ‘collection’ is not defined in list or in any of
> its sub-objects.  This would enable the inheritance of ‘list’ in ‘testSuite’
> to be flagged as illegal (because the definition of a method called
> ‘collection’ will make the definition of ‘list’ illegal).
>
> Other solutions involve chaining the name resolution rules.   For example,
> if all self requests had to use an explicit self, then lexical bindings and
> dynamic bindings would be syntactically distinguishable — this is the
> AmbientTalk solution, I believe.  Another possibility would be to say that
> all inherits expressions are lexically bound, and that the dynamic chain is
> never consulted when resolving them.   (I think that this would change the
> language in significant ways, because it would effectively introduce private
> methods and variables.  It also seems a bit strange to have one rule for
> inherits expressions and another rule for other expressions.)
>
> I’m guessing that Michael’s email is an attempt to look at alternative name
> resolution rules, but I don’t understand how his rules would deal which this
> example.
Under "local" and "OC", "collection" resolves lexically. Under "Q", it
is a selfcall.
-Michael