[Grace-core] Dialect Design Proposal

[James Noble]

On 29/11/2012, at 13:00 PM, Timothy Jones wrote:

> tl;dr Make constructors the fundamental OO concept in Grace.

Hi Tim - a long message, with some interesting ideas.  
But probably not a "silver bullet" I'm afraid - because I don't think there is one.
But I'm still wiling to be convinced

> object { method foo {} }
> // Can be described exactly by:
> constructor { method foo {} }.apply

so this seems a lot like how 

object { method foo {} }
// could also be described by 
(class Foo.new { method foo {} }).new 

(well almost!) 
That is: Tim's constructors seem like classes to me, with a single "new" method
that doesn't take parameters. 

> The magic arises when a call to a constructor appears as the value of an
> inherits clause.

in other words, when one class (constructor) inherits from another,
the "self" is late bound - like the "Satanic" Grace design - or like Java classes :-)
This means that the "inherits" clause semantics are *not* compositional 
(to use Andrew's terms)    calling a constructor from an inherits clauses
rebinds self, but calling it from anything else doesn't. 

In this scheme, objects (Object literals) can also inherit from classes, because they can be 
rewritten as object-constructors (i.e. classes). 

> So object inheritance uses Self-style delegation,

So talking to Tim, this part of his proposal didn't seem clear from his email.
I think it means you could also write 

class Bar {
 inherits Foo.new   // inheriting from a ground object, not a class (object constructor)
}

and at this point, this is treated as delegation like Self, or like Grace before we changed the semantics of inheritance.

> This satisfies our goals! Objects can inherit from objects, classes can
> inherit from classes, objects can inherit from classes, classes can even
> inherit from objects, they're all defined in terms a fundamental
> concept, and inheriting from an object in no way affects the identity of
> that object or any other objects inheriting from it.

well yes - except really we have classes as the fundamental concept,
layer objects on top of them,  and have two "inheritance' like semantics -
class inheritance semantics if you inherit from a class, and object inheritance 
semantics if you inherit from an object - both sharing the same syntax.

>  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.

> I eagerly await your input on how this solution that appears to solve
> all of our problems is somehow utterly flawed.

It's not utterly flawed - but it has its own selection of strengths and weaknesses
 + supports Kim's ideal, Java like class inheritance semantics 
 + supports delegation
 - introduces objects constructors as a separate concept and defines classes & object in terms of them
 - defines object literals and classes in terms of these constructors
 - has two different inheritance mechanisms 
 - with one piece of syntax.

you could tackle that last one with a different keywords for object and class inheritance - 
but now you've explicitly got two inheritance mechanisms in the language. 

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

or at least that's my reading of it 
J