[Grace-core] Name resolution in Grace

[James Noble]

> As a general principle, it seems hopeless to be truly modular against
> changes to base classes. I would guess the same is true for dialects.

yes, I'd by that. Dialects are easier because they're "lexical".
Private (it seems to me) makes many things worse - notably
tangling request resolution (aka method sending) and accesbility.

> You *have* to know what language you are programming in, don't you?

indeed!

> For what the specific rules should be, I never know when I am just
> unimaginative, but the following approach that Michael described is
> used quite widely and is at least reasonable:
> 
>> Resolution means, in effect, syntactic transformation
>> to have an explicit receiver, which will follow the ordinary lookup
>> rules.

What's nice about this is it then follows the "normal" rules:
it's just a question of getting the transformation right.

Although I am always a bit weary of "syntactic transformations":
we need to report errors and debug the code that's actually written.

> With the static rewrite approach quoted above, you could think about
> override with the slogan, "methods override methods". When you write a
> method down, you *know*, statically, which other methods you are
> overriding. No matter how anyone calls the original method, your
> method will intercept it and get a chance to run.

right.   Although even in Java, moreso in Newspeak & Dart, you don't
know, statically, which methods you're overriding (because your super-class
can be somewhat late bound)

> The original motivation to allow foo()
> instead of self.foo() or outer.foo() was, I would think, that the
> receiver is too obvious to merit writing down

also - from Self - that it's there everywhere, so there's no merit in writing it down
(even though Smalltalk people do write self down everywhere if they're using 
accessor methods)

> Now, we have reached a point where if you write foo(), you aren't so much eliding obvious
> boilerplate as asking for additional dynamism in the dispatch algorithm.

Additional dynamism depends on the rules you pick, I think.
Newspeak's out-then-up rule depends only on "lexical" information
(which for us must include dialects) and doesn't depend on self's
superclasses (because they can be very late bound). 
Unsurprisingly, the interesting case is "self". 


> All of this makes the Python and Smalltalk approach look tempting,
> doesn't it? If you are calling a method, you have to write down a
> receiver. It makes code longer, but it also makes code clearer.


it makes OO code uglier (to my eyes) than non-OO code:
for me at least, it's a problem if we end up there. There's 
a difference - aesthetically at least - between an OO language
and a procedural language with an OO extension.   And of 
course, both Python & Smalltalk treat methods and variables
asymmetrically. 

James