[Grace-core] Name resolution in Grace

[James Noble]

On 9/07/2013, at 22:58 PM, Andrew P Black <andrew.p.black at gmail.com> wrote:

> I wonder if it's time to revisit those decisions?

oh I hope not again!

>  Suppose that  Grace actually had (lexically-bound) procedures as well as (dynamically-bound) methods, and all methods had an explicit receiver?   Yes, that's one more concept.  

I find it hard to explain the different (or, quite often, understand what people mean by 
"method" "function" "procedure" as it is).  I don't think baking that distinction in 
to the core of the language is a good idea.  We've already got OCAML & Scheme.

> But don't the name resolution rules get dramatically simpler?  

not really - because now we have two different sets of rules, and two options for everything.
What if you declare a "method" but call it as a "function" or vice versa? 
When you're writing your program, how do you decide?

Again, Ambient only distinguishes on the calling side: x is always lexical, self.x always virtual.
So people will always write just "x" until inheritance comes up, then you have to explain
the different, and which one to use --- the answer being (especially for people who 
don't like "final")  --- always write "self.x"... 

I think this takes us to (effectively) a procedural (or ML-style) language with objects bolted on.
ML without algebraic datatypes or type inference, but with structural, gradual objects...

> And now we get "private methods" (aka procedures) too.

we can have "private methods" or lexically bound procedures if we really want them today:
just permit them to be declared in a lexical scope (method or block scope basically).
Scala has always done this - and I don't think its the lexlcal-vs-dynamic (vs static)
binding that makes Scala's operational semantics hard to understand...

but you know I think all this already...

James



PS - here are two slides from the Grace talks I've been giving
although I haven't got to them recently.

The first one outlines our problems - 
the second outlines the problems wtih a two different worlds model


------------------------------------------------

class SuperClass.new {
   def m = "in superclass. "
} 

  def out = object { 
    def m = "in enclosing object. " 
    def inner = object { 
       inherits SuperClass.new
      method foo { print (m) }  
     } 
  }   // how to resolve lexical vs dynamic binding?


------------------------------------------------


class SuperClass.new {
 function f { "function in superclass. " }
 method m   { "method in superclass. " }
} 

def out = object { 
 function f { "function in enclosing object. " }
 method m   { "method in enclosing object. " }

 def inner = object {
    extends SuperClass.new
   method test {
      f       // prints “function in enclosing object.”
      self.f   // no such method error
      m      // no such function error
      self.m   // prints “method in superclass.”
   }
 }
}
------------------------------------------------