[Grace-core] Name resolution

[Andrew P. Black]

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.

	Andrew

	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150322/71b48e23/attachment.html>