[Grace-core] Minutes of Teleconference 2011.10.05

[James Noble]

admin:
 - not to do SIGCSE BOF this year
 - aim to write some papers next year! 
 - Grace BOF at SPLASH on monday night 
    - need to think carefully about how we present & what our aims are
 - Grace Design workshop on friday 
   -  Dave Ungar is giving a talk at 13:30 at PSU on Friday at 13:30.  The rest of that day will be a Grace workshop.


content:

> * <> vs []   :-)   ---  yes, we've heard what people have said on the blog, would like a bit more feedback

We agreed (I think):

That at the beginning language levels, indexing should use a named method (like .at).
However, we will reserve [] with the intention that, at higher (professional, expert) language levels, [ ] can be defined as an "aroundfix" message symbol, with user-defined semantics.  FIrst suspect for such a symbol are .at and .apply

(An aside: I'm wondering if it would clean up our syntax a bit if we regard message names as being symbols (like +) or starting with a . (like .at).  Previously, I regarded . as a separator, doing between an object and the message name.)

Consequently: we should use < and > (or ‹ and ›) as type brackets.  We don't know if the former can actually be parsed, or if it will lead to confusion with messages named < and >.  (Factories might well have such messages, so this might required look-ahead to see what follows the <).

> * model of (generic) object creation - if it's Factory[Types].new(args) , what's Factory[Types] ? 

It's Factory<Types>.new(args).  Factory<Types> is "a type-annotated version of Factory".  We didn't get into what this really meant.


We talked about rules for type conformity with Dynamic.  Dynamic seems like it is type-equivalent to Any, in the sense that a variable of type Any can have a Dynamic assigned to it without any type problems (and vice-versa), but a variable with a more restrictive type can't have a Dynamic assigned to it unless its type is first checked using a withType expression (cast).  The pragmatic distinction between Any and Dynamic is that the necessary withTypes are inserted by the compiler, and need not be written by the programer. (A tool in the IDE could certainly highlight these otherwise invisible withTypes.)

What does this mean if a dynamic object d is passed as an argument to a statically typed method?  It means that all of d's  "outputs" (the results of d's methods, and values passed by d as arguments to methods of statically typed objects) must be wrapped in withType expressions determined by the context in which d is used.   Note that self-requests from d (to itself!) need not be wrapped.

What does this mean if a statically-typed object s is extended to create a dynamically-typed object d?   It means either that
(a) all of the methods of s that perform self-requests to methods that are overridden in d need to be recompiled in the dynamic context, or that  
(b) those self-requests are wrapped in withType expressions.
Note that s itself doesn't change, and is still statically typed.  It's only d that is dynamic, which ought to be expected.  The only "surprise" is that some code that a Smalltalk or C++ programmer might expect to be shared between s and d is duplicated, so that it can exist in two different variants.  (This is a bit like the heterogeneous implementation of generics.)

Respectfully submitted,

	Andrew


todos:
* andrew & james to attack COOMP talk closer to the time
  plan was to go through Birger's paper and address each thing
    andrew asked about user-defined relationship implementations under the syntax
    It's getting closer to the time...   

open (or more contentious) issues for discussion next time:
* model of classes/objects 
     - see James' rough notes below - I wasn't able to expand on this but can try to explain 
* model of (generic) object creation - if it's Factory[Types].new(args) , what's Factory[Types] ? 
* singleton types? 
   - what's a singleton type, how is it declared, what does it mean, is that consistent overall?
* the module system
* tuples? 


* design hasType/ withType/ typof/ getClass/ getType etc
    AFTER the main question of classes vs objects is resolved...
* think more about language levels
    which ones we want:  novice/ standard/  full?
    how to describe them  (the test for the module system)




* class vs objects

I've been looking at Rust, and thinking about Go this week.

Both of them have objects with "structural subtyping" (neither of 'em have dynamic).
Neither of them have traditional inheritance. 

Go has "embedding" aka anonymous fields - http://golang.org/doc/go_spec.html#StructType
 - Fields and methods (§Method declarations) of an anonymous field are promoted to be ordinary fields and methods of the struct
 - Go has a receiver, but not real "late-bound-self reference" --- forwarding semantics, not delegation semantics

Rust has objects but "no object hierarchy" - https://github.com/graydon/rust/wiki/Object-system-design-and-implementation 
   - Rust pretty much has object prefixing a la Antero.
  - Rust has "self" (used only as a prefix, not as a value) but doesn't seem to have super
  - and the spec doesn't say how methods (& field) are added to objects, but the web page does
  - "Rust has a lightweight object system based on structural object types: there is no “class hierarchy” nor any concept of inheritance. Method overriding and object restriction are performed explicitly on object values, which are little more than order-insensitive records of methods sharing a common private value."
- see also https://github.com/graydon/rust/wiki/Object-types

These cut-down systems have had me asking which features do we really need:
- objects 
- classes 
- inheritance 
- self
- super
- delegation semantics ("late bound self-reference")
- forwarding semantics 
- static inheritance/delegation/prefixing/whatever etc 
 - or dynamic/arbitrary object delegation
- multiple inheritance (aka simple traits, scala style)
 - or full trait operations?
- nesting
- ...?

Options for Grace:
"Rust Design" 
- scrap classes: have only objects with prefixing as part of object definitions (Rust style)
   - objects types must now be "complete" (incl private methods) rather than just interfaces
   - either emerald style parameterisation by scope, or Rust style constructor functions
   - I guess generics could be incorporated (at least with constructor functions)
   - will a language without classes be acceptable?
OR
"Smalltalk Design"
- scrap object declarations: have only class declarations
- classes inherit from another class declaration
- single constructors as per current design 
--- or (following Newspeak) could have multiple constructors...
OR
"Scala Design"  (perhaps "modified scala design)
- have object expressions and class declarations as currently in the spec
- objects & classes only inherit from class declarations
- single class constructor as per current design; use "companion factory objects'"  if you want more
- object expressions create new instance on each evaluation
--- or (following Scala & Self rather than Emerald) object declarations could be singletons, only run once