[Grace-core] Minutes of Teleconference 2011.09.22

[James Noble]

admin:

* aims for OOPSLA -  can we demo something? will it be too offputting?
* SIGCSE BOF - due Oct 24 - http://www.sigcse.org/sigcse2012/authors/bof.php
* POPL workshop  (early Oct) - probably not
* When is Andrew Visiting NZ?  most likely mid-year NZ


content: 
 * on instanceof / cast - still have to quibble on syntax
    * principles: keep base separate from meta
       keep intercession separate from reflection
 * on types
       principle - allow definitions/abbreviations for types to help error messages...
       operations allowed on variants:  anything they have in common (arg & ret types are the same)
       happy with the T | nil  design  (if it works - the difficult is singleton types)
           ideally programming style is "null object" pattern...
       remember the "unitialisied variable" marker
       names for: Any(no methods) - top & None(all methods) - bottom 
        every object is Any, no objects of type None
        dont want to use Object as we have an "object" keyword
            principle: our declared names shouldn't differ from keywords only in case           
         list & and + typeoperators as (options)


open (or more contentious) issues for discussion next time
* collections (& tuples?)
      - see blog post
* model of classes/objects 
       - see notes below?
* <> vs []   :-)   ---  yes, we've heard what people have said on the blog, would like a bit more feedback
* 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


todo: 
 * everybody: thing about the top couple of open issues
 * James:  what's the dynamic type of a dynamic object?
       does an objects' dynamic type ever change?
 * James: try to work through Andrew's idea of types as annotations
       put all annotations generally in angle brackets
 * 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)
* 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




* 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