[Grace-core] Name resolution in Grace

[James Noble]

>> Method requests with arguments (method(arg)) and an implicit receiver may mean either outer.method(arg) or self.method(arg).  How can we tell?... I think that the right answer is to request the outer method, if there is one, otherwise to make a self request. If programmers wants the self request, they can write self.method(arg).

> It is untenable because method names are part of the interface of an
> object and so clearly can't be banned. Forget about inheritance and
> anything else.

I'm not quite sure what Michael is getting at here?

on the other hand, given something like this

def 0 = object { // outer object
   method m {...}

   def i = object { // inner object 
       method m { ... } 

      method question { m } 
   }
}

it seems perverse that the call to "m" in "question" resolves to the outer object o.m
rather than "self's" o.i.m.  My reading of Andrew's rules later confirms this, resolving
to "self.m" aka "o.i.m".   If the "m" is inherited, rather than being directly in o.i.m.
then this argument doesn't seem as strong.
  

> I think this is too complicated (jumping back and forth)

yes it is, which is why I'm very keen on finding the simplest 
elegant, workable solution  (not just the simplest)

> and they should in general just be disambiguated by the compiler.

well yes - but it's also very important the rules are clear,
so that we can explicitly teach them to students, and even
examine them on the (consquences of) the rules directly -
generally by asking them to hand-evaluate or debug a program.

> How about:
> 1) Look at names in the current scope (i.e., names that would be
> available if this scope existed without any surrounds). If a matching
> name exists, resolve to it and terminate.

I'm not sure this is quite right - or at least its underspecified as it stands.
There's a difference between "resolve to it and terminate" and what you
imply later on - that if we "resolve" to a name in an object scope of 
self of its superclassses/superobjects...
we treat it as a "self" request - rather than just resolving and terminating.
Basically we want all self requests to be late bound: if we're actually
in a "subclass instance" then  we will actually "resolve" to the subclass's
definition. 

> I don't think unresolved names should be late-bound on self - that way
> lies dynamic scoping madness, only worse.

I don't see why - if the evaluation rule is clear enough, everything should 
at least be understandable.  Most (if not all) "dynamic" OOLs do this,
including I think Smalltalk Self Newspeak Ruby Python... and it's not
a big mess.

The question is: if the typing system is gradual, do we want the (in this case)
"abstract annotation" system to be gradual as well  (to get rid of this problem,
assuming suitable binding rules :-)  you can just have to declare the "missing" 
messages, conceptually abstract methods, because they must actually be
filled in by subclasses,,, 

I mean, it's quite possible to require such abstract methods even when the rest 
of the program is statically types - but it does seem a bit odd to me

James