[Grace-core] Name resolution in Grace

[James Noble]

On 5/07/2013, at 16:41 PM, "Andrew P. Black" <black at cs.pdx.edu> wrote:

> We have been having a discussion about name resolution in Grace

yes- and I'm glad we're continuing this virtually!

> I propose that x should in these cases always be lexically-bound, if a lexical-binding exists.


OK.  That's clear, but I'm not sure it's what we want (OK speaking plainly: what I want).
Then, after reading on, I decided it is perhaps what I want, but isn't clear.

I guess my question is: what's a lexical scope?

> — if x is a variable, definition, or parameter in the current lexical scope, then x refers to that variable, definition, or parameter.   ("Current lexical scope" excludes the enclosing dialect, since names defined there are not actually visible "on the screen".)   

If a "lexical scope" is just a method or block activation context then I think this is OK - 
but it's odd because, well, declarations (methods and objects and...) are in some
sense "lexically nested" inside objects or classes.  

I think I said yesterday I'd be happy with a "lexical names bound lexically, 
object names bound dynamically" rule.

> — if x is a method defined in the current object, or in any of its super-objects, then x means the method request self.x

I think this is important - otherwise "x" (lexical) means something that I'd find confusingly different to "self.x" (dynamic) when "x" is defined in self.

> — if x is a method defined on the enclosingn object (including inherited methods), then x means outern.x.  Thus, if x is a method defined on the enclosing object (including inherited methods), then x means outer.x; if x is a method defined on the enclosing enclosing object (including inherited methods), then x means outer.outer.x, etc.

the enclosing object must be the object enclosing "self", right?

> — if more than one of the above applies, then x is ambiguous, and the programme is illegal.  The programmer has to fix it, either by adding explicit selfs or outers, or by renaming the variables in the enclosing objects.


there is another case - that "x" will be / should be defined in a subclass of self.
presumably there should be no runtime error in that case.  We could require a 
local definition in such cases through - Java does this (and you mark the local
definition abstract), but Smalltalk doesn't of course.

> To this end, names in an "enclosing" dialect should not be in the lexical scope of entities written in the dialect.  (This was Martin Odersky's suggestion — lexical means within the current compilation unit, and thus visible on the screen in front of me.)

I do think this is a very nice way of thinking about things.
We had this rule in the dialect paper, but it looked like a bug.
Now it looks like a feature, and we can thank Martin.

comments?

cheers

James