[Grace-core] Minutes of Teleconference 2011.11.30

[James Noble]

(listed as 2011.11.30 because I'm in denial that it's already December..)

* decided none of us liked declaration-side distinctions between lexical & inherited functions

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

* considered that the "no shadowing" rule may eventually be moved into a dialect rather than core spec 

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

* talked about Michael's "Polymorphism over unit" message

* switch design to return "none" vs not returning anything etc...

  "none" is a trivial value object - that understands no messages etc.
  assuming singleton types work, this can be used as a singleton type "none" 

  now every method request  returns a value, even if that value is none. none is assignable to suitably typed variables.
  primitive assignments return "none"
  most control structures (especially while, for)  return "none" 
    if then else & match can just return the value of the block that was executed (which may or may not be "none")
   a method that ends returns the value of the last expression/statement (which may or may not be "none")
   writing just "return" returns none
      leaving off the "->" in a method declaration means -> *Dynamic*

And then:
 * Andrew's solution in dynamic world - that somehow applies at only lower language levels
      dynamic checks on assignment & parameter passing  
       that prevent assigning "none" to a variable, or passing "none" down as a method argument.
       return values are *not* restricted...

 * Kim's solution in the static world - if you could have a *none*, you'll need to mention that in the types
      (one way or another)

what Scala does - http://blog.sanaulla.info/2009/07/12/nothingness/
  (5 different null-like things)

what Python does - http://boodebr.org/main/python/tourist/none-empty-nothing
  (3 different null-like things :-)

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

default accessibility - decided on everything private 
  "private" here means  may only be requested on self (Java's protected not Java's private)
  "public" annotation to make things public
       this makes James & Andrew's toes curl, but we should live with it and see...
       we considered versus alternative design:  methods public, vars private, def public 

This seems like a natural BLOG POST - Andrew will draft something
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 

Finally, James & Andrew talked about the "inheritance question"
Given something like: 

class MySubclass { x -> 
  inherits MySuperClass.new(x)  
}

the spec currently says:

> The right hand side of an inherits clause is restricted to be 
> a class name, followed by a correct request for that class’s new method."

we propose to relax this to be something like 
 
> The right hand side of an inherits clause is restricted to be 
> an expression that _definitely statically_ resolves to an object constructor call
> or to a correct request for a class's new method.

where _definitely statically_ is defined as permitting only
  - accesses via effectively non-overridable "defs" 
     - defs found in lexical scope
     - defs that are annotated "final" (or "nooverride" or something like that" - "static", "broken"...)
  - accesses via effectively non-overridable "methods" that return object constructors. 

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