[Grace-core] Name resolution in Grace

[Michael Homer]

On Fri, Jul 12, 2013 at 10:03 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> So I've been thinking about this while travelling to EuroPLoP
> (where I am now, great place but not too much time for email)
>
>>> Well, I knew that you wouldn't like this.  But I'm still waiting to see what you would like!
>
> I quite liked the sound of Martin Odersky's rule we talked about last week:
>
>> (This was Martin Odersky's suggestion — lexical means within the current compilation unit, and thus visible on the screen in front of me.)
>
> this (I think) gives version of Newspeak's rules:
>  - things in method or block scope are lexically bound
>  - things on Self are dynamically bound
>  - things on outer are lexically bound - Newspeak doesn't look up the superclass chain
>      when it is resolving implicit sends to outers.
>
> It's attractive in that you never have to look "too far" to find things - although we'd probably want to follow inheritance of the dialect itself, which looks rather a special case.  I'm not sure if this supports
> all the family polymorphism patterns (although perhaps that's a good thing)
You do have to write "self.x" all the time, which is the thing you don't like.
>
> Michael's rule is straightforward "up then out" I think, the gBeta rule, perhaps also the Java rule?
>
> 1) Look at names in the current scope
>  - names declared locally
>  - names inherited (if the current scope is an object)
> If a matching name exists, resolve to it and terminate.
> 2) Go out one scope, and forget about the scope we were in before.
> 3) Go to 1.
>
> this works (reasonably) well with the concatenation story we tell about inheritance:
> that pretty much requires inheritance to have a higher priority than scope or object nesting,
> but it does make strange things happen if an outer-super-class accidentally redefines something
> defined in a dialect --- and (depending on what "names inherited" actually means)
> even weirder things happen if an outer-sub-class overrides stuff.
>
> There is also a question of binding time - self must be late bound, but *how late*?
>
> How dynamic do we want the dynamic / untyped programming style to be?
(Local names of) receivers should be statically determined. Otherwise
you never get any static errors from typos (even in statically-typed
code!).

I would like to mention the type-of-self problem again. I don't think
code can ever be entirely dynamically-typed because of it.
> I have been trying to think about cases like the one listed below - but then my head just hurts:
>
> module foo.grace ===============
>
> class Foo.new {
>
>     class FooFoo.new {
>        method doit {foobaz}
>     }
>
>     method foobaz {print "FOO"}
>
> }
>
>
>
> module bar.grace =================
>
> import "foo.grace" as foo
>
> class Bar.new {
>    inherits foo.Foo.new
>
>    method foobaz {print "BAR"}
>
> }
>
>
> Bar.new.FooFoo.new.doit
This prints "BAR". Name resolution doesn't even come into it; there's
only one receiver.
-Michael