[Grace-core] Dialect Design Proposal

[James Noble]

>>> there's a simple (and true) story
>>> that can be related to students about how inheritance works: delegation.
>> unless it's class inheritance, in which case it's class inheritance.
> 
> Well, part of the point was that, discounting the magic passing of self
> from the inherits statement,

I guess my point is that you can't discount this.
This is also Andrew's point when he asks if the inherits clause is "context sensitive"
or if you can inherit from "any arbitrary object" 

> class inheritance still uses delegation but
> is indistinguishable from normal class inheritance because the objects
> being delegated to cannot be referenced from any other place (just like
> the freshness system).

I bet there are evil tricks that can distinguish - but I'm sure they are *evil*...

method yourself {return self}
def inner = object { 
 method outself {outer.yourself}
}

>> I still end up with this list:  PICK TWO:
>> 1. "classical" inheritance semantics - "self" bound to sub-object while super-object literal executes
>> 2. inheritance from an arbitrary object
>> 3. a simple explanation of classes in terms of objects
>> 
>> Tim's proposal keeps (2) because it as two different inheritance mechanisms,
>> class inheritances keeps (1) but object inheritance does not.
>> at (3) either both classes or objects are now explained in terms of "constructors"
>> or objects are explained in terms of classes - not the other way around
> 
> Right.

OK good so at least we two understand it!

> Basically I think the becomes implementation is unexpected and
> has a lot of edge cases,

perhaps 

> but that we can't describe classes properly in
> terms of objects if we use delegation.

yes

> It's not possible to write an
> encoding of the desired inherits semantics with just objects. However,
> if you think that becomes is an acceptable solution, then that's irrelevant.

"becomes" is what we've got now: it's not just up to me as to whether it is acceptable. 

Here are some questions that may help think about this:
 - how many syntaxes should have have for "entities"?
 - how many different kind of "entities" (objects/ classes/ constructors/ traits) should we have?
 - should we have one or two "sharing mechanisms"  between entities (inheritance/delegation/contatenation)?
 - if more that one, how should they be distinguished syntactically?

Java for example:
  - has two entities - objects and classes/types/interfaces  (being nominal, classes & types are unified)
  - has explicit syntax only for classes  (and for literals of a few private types, strings, ints etc)
  - has two sharing mechanisms - extends and overrides
  - each has their own keyword

Self
 - has one entity - objects 
 - has explicit literal syntax for objects, (and a few private times)
 - has one and two halves of sharing mechanisms  (delegation via private fields,  "dynamic" delegation via perform, and concatenation via _AddSlots/ CopyDown) 
 - all sharing mechanisms are distinguished syntactically  

Grace 
 - has three entites (more or less) objects, classes, types
 - has explicit syntax for each (objects, classes, types) plus a few primitive types
 - currently has just one sharing mechanism "inherits

how would you characterize your proposal in this taxonomy?  
(I can think of at least two different ways)

J