[Grace-core] Name resolution in Grace

[Michael Homer]

On Sat, Jul 6, 2013 at 10:52 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
>>> 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?
"It" was the no-shadowing rule that banned defining these - I don't
see anything much wrong with the rule that bans ambiguous lookup,
except that it's unnecessary. It doesn't break anything any further.
>> 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.
There's only one way to resolve to something that's dynamically bound,
like a method. Resolution means, in effect, syntactic transformation
to have an explicit receiver, which will follow the ordinary lookup
rules.
>> 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.
Python certainly does not do this. It doesn't have implicit-receiver
calls at all - you have to write self.x() always, and plain "x()" is
invoking a first-class function in lexical (not object) scope. Ruby
does, but it really does have dynamic binding in classes (it's how all
those DSLs work). It doesn't have non-local lexical binding at all,
though.

I don't think deferring errors from mistyped variable names to runtime
is helpful to anyone. It would have to happen for statically-typed
code too (but a dialect could check). Delaying errors from explicit
"self.x" might be ok, I guess. You would have to treat outer.x,
outer.outer.x, etc the same way too regardless.

There is a lingering issue about the static type of "self" - it seems
it has to have one, even in otherwise dynamically-typed code, because
there's no way you can turn it off.
-Michael