[Grace-core] Lexically Scoped Variables

[James Noble]

What's that mean?  Or why variables should be bound just like
everything else?

Imagine reading a Grace program. You come across a name without a dot
before it - an implicit request - and you want to know what it does,
where that requires may be answered.  What rules do we need to teach
students to read their programs?  Here is my take on the current
semantics:

-1 Does it have a dot, or is an operator?   Then it's a "public
 request" with a receiver, and is dynamically bound by the receiver.


0. is it a special name like "self", "super", "outer"?

It's special, it's not a method request.

1. look in outer objects, any any traits they inherit, out to the
enclosing module (and its traits) and then the dialect and it's
traits.

If your name is defined there, then this name is resolved as if it was
an outer request to that object.  (lexically bound I guess)

[Most nested object languages have this rule.  Newspeak has a variant:
it but doesn't do the "and their supertraits" bit. Hopefully most
intermediate objects *won't* inherit from anything.]

[note that - depending - if the name is *also* defined in one of your
inherited traits, that might be an ambiguity error. But let's assume
the program is correct: you're just trying to figure out what it does]

[similarly an outer request to a "Local" name - I can't remember that
annotation - is an error]

OK, so it's not defined in an outer object. Then:


2. Is it a multipart method name, or a single world name with
arguments in brackets (like "foo(2)" or "foo[3]")?

Then it's resolved as it if was a self request: start the lookup in
the object constructor defining the object, then its inherited
traits, up to the top trait.  (dynamically bound)


OK so it's must be a single word name, perhaps ending in ":=", not
defined in any outer objects.


3. Is it defined in the "self" object containing the code you're
reading?  If NOT, then it is resolved as a self request, dynamically
bound.

OK, so it must be defined in "self": 

4. is it a method or a def (or a type or a trait)?  It's dynamically
bound.

OK, os it must refer to a variable --- say V.

5. if it's plain "v" and the variable is readable, it's dynamically
bound, a self request.

6. if it's "v:=" and the variable is writeable, it's dynamically
bound.

7. it must be either "v" to a non-readable variable, or "v:=" to a
non-writeable variable: it's lexically bound straight to that
variable.  Subtraits or the object constructor don't get a look in.

========================================

I think this is very messy indeed. I propose that we eliminate the
"lexically bound" rule for variables. 

That leaves us with only the following cases.

-1 public requests - (dot or operator) resolved dynamically to the receiver
0  magic keywords are magic
1. outer requests - resolved lexically to the outer object
2. self request - resolved dynamically on self. 

and that's it.


========================================

For completeness, a few more rules expanding on -1 above.

-1 any expression followed by a dot and then a name, perhaps some
 arguments, perhaps some more names and arguments is a **public request**
 of that message to the object returned by the expression.  

All public requests are resolved dynamically, by starting at any
definitions in the object and then going up through its inherited
traits. A public send that reachers a
private/protected/confidential/blah method is always an error.

-2 any operator (expect the special ones) between to other expressions
is an **public request** of that operator to the left hand expression,
passing the right-hand expression as an argument.

-3 any operator (except the special ones) followed by an expression is
 a **public request** of that *prefix operator* to the object returned
 by that expression.

operator requests are like any other public request: they just look
funny. But they're all dynamically bound.


[not sure about the "public request" terminology. "External request"?
Not at all the same thing as an "outer request".  Perhaps
"implicit/explicit request" or "reliever-less request/receiver
request" or  "external/internal" request...]