[Grace-core] Minutes of Teleconference 2011.10.12

[James Noble]

* admin / todo: 
  - coomp talk
  - monday night talk  
    --- for both, james to cons up his existing talks (Coomp) & existing grace talks (monday)
    --- aim for monday BOF - show examples,  show progress, recruit :-)

* next meeting - either 3pm tue or wed (US) ;  either 11am wed or thur (NZ)
 
* james has updated spec on type system, 
   - will keep going re pattern matching

agreed on content:
* talked through singleton types - agreed proposal (as in spec) should work :-)
      "static types are statically typed", in the type context, we  know statically if a name is a (static) type. 
* when we ask an object what is its type is, then we get the structural type  (not singleton type)
* agreed on a single namespace - types, objects, methods, all in a single namespace
* single value space - agreed, presumably evaluating a type as an expression returns a (limited) metaobject
* how do we handle language levels
       - "language upper-hemi-lattice"
       - must be able to call inter-language
       - classic case:  dynamic student code calls static libraries...
   * agreed nested objects / scoped defines language positive features
   * checker defines langauges negative features... 

things to talk about next time
   classes & objects (mailing list copied on below)
   

things not to forget to revisit 
    privacy
    metadata
    design hasType/ withType/ typof/ getClass/ getType etc
    modules
    tuples

=== carried over objects & classes discussion ===============

James
> Kim
>> James 

>> * class vs objects

the catch with this, of course, is we all have to agree :-) 

>> 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
> 
> I think something like this is a non-starter given our target audience.  People need to be able to teach a language that has simple, reasonably-easy-to-understand inheritance with classes.  I see being able to define objects as a plus as well, but we need to be able to write something that looks like class inheritance and a late-bound self.  Otherwise very few people will be interested.

I agree with this too...

>> 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
> 
> I have students write programs early on where they pass "self" as an argument.  It comes up very naturally in event-driven programming as well.

right.

>> - 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
> 
> I think strong arguments can be made for all the features above this line.  Many instructors won't consider the language if it does support these features.  Some of the features below this line can be added if necessary, but we run the danger of making the language more complex (conceptually!) if we add too many.
> 
>> - 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?
> 
> Absolutely not.  We need to support syntax with classes.  In principle they could be defined from simpler concepts, but the syntax must be available.  Moreover, the notion of destroying abstraction by having the types of private methods bleeding through to object types is unacceptable.  I spend much of the first year (especially the second half) drilling into students the need for abstraction.
> 
>> OR
>> "Nonreflective/Modular Smalltalk Design" / "Dart Design"
>> - scrap object declarations: have only class declarations
> Why scrap object declarations?  They seem to have good pedagogical value.

only because I was trying to scope out the conceptual space - 
and Dart & ModST don't support object literals. 

>> - classes inherit from one other class declaration
>> - single constructors as per current design 
>> --- or (following Newspeak & Dart) could have multiple constructors...
>> -- Dart makes constructors "special"  (with a "new" keyword);  Newspeak doesn't. 
> This would be an OK design, but not my first choice
>> OR
>> "Scala Design"  (perhaps "modified scala design)
>> - have object expressions and class declarations as currently in the spec
>> - objects & classes only inherit from one 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
> 
> This would likely be my choice.  I have mixed feelings about the choice of object expressions being generative or just representing singletons.  I could likely live with either choice.
>> 
>> We'll have to think about how we compose the libraries (so this relates to the module system too) 
>> - imports
> yes
>> - multiple inheritance?
> definitely no
>> - convert classes to mixins & compose them  (Newspeak)
> not a big fan of
>> - class extensions (Modular Smalltalk)
> no
>> - simple (nonalgebraic) traits?  
> if we feel they are important enough.  As a language for novices they might not be needed, but could be part of the most advanced language level.


I think the key use-case for modules - or whatever we end up with - is really to compose up the language levels.
Then, representing higher level designs. I think we are making conceptual progress through the woods here
but we're not out yet.

James