[Grace-core] Concerns about Grace's design

[James Noble]

The week before last, we had a series of off-list emails, kicked off by Andrew, going through some concerns about parts of the current design. Here's my summary of this discussion:

> Inheritance.  The two stories that we have to explain inheritance — object mutation and "deconstructing" and object to get it's initializer out, both smell bad to me.

* the current semantics - the sub-object is concatenated to the super-object - is close to that of "Java-like" languages, and seems to do most of what we need. 
* we never adopted any kind of deconstruction/extraction semantics.

 In terms of this list, posted sometime around August 3, we pick 1, so trade of at 2 (a little) and 3.
* Reiterated from last week: 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

> Dialects.  The Onward! paper says that we use inheritance to get dialects.   This sounds good — reusing an existing feature.  Now we are talking about defining dialects using macro-expansion.   This also smells bad — macros are a symptom of lack of expressiveness.

Neither Andrew nor & I like an explanation based on macro expansion.

I think we're all agreed on requirements for dialects, basically, dialects will define sub-languages,  and implementation specific methods in dialect definitions should not affect programmers using those dialects.   If we had "private" methods this would be easy with inheritance; an annotation parallel to "private" could be used if dialects were logically the outer-most lexical bindings.  

In some ways the most important question here is about whether dialects are objects or classes, and what happens to their state.

If a dialect (like a module) is basically an object, then this works OK if the dialect is essentially a singleton and there should be one dialect "instance" shared among all modules in that dialect. This works in a model where module-objects are logically/lexically nested inside dialect-objects: some kind of annotation would be needed to hide the dialects implementation internals.

If a dialect (unlike a module) is basically a class, then with the concatenation inheritance semantics, its easy to instantiate multiple instances of the same dialect for multiple modules. This works in a model where module-objects logically inherit from a (fresh instance of) the dialect, but again we'd need some mechanism, (presumably either a provider-class annotation like "private", or a client-class annotation like "inherit only public") to protect the dialect's internal implementation. 

> Receiver-less requests.  They used to be self requests.  Now they are either outer requests, or self requests, depending on where a definition of the method can be found.  Outer requests are lexically bound, I think, whereas self requests are dynamically bound.

Receiver-less requests have been either outer or self requests since we adopted object nesting.

There are some questions about corner cases - see another email on the pathological super-outer-object example -
but it seems Grace is in company with at least Scala and Java here. 

> Immutable objects.  We started off saying that they were important, but now we can't even say whether or not an object is immutable, because it may have captured mutable state in a method.  I think that we need to tackle variable-binding head on. This is necessary for clone and egal, as well as immutably.

This discussion went further - getting to the point that while "shallow" (just the fields in the object) or "semi-shallow" (also including lexical bound variables, typically in outer objects) is clearly a problem, the more general case includes methods requested by an "immutable" object that themselves depend on mutable state.  This points towards some kind of general "purity" system, ideally instantiating some kind of generic metadata framework.  We are early days here:  James is about to send another message about that!

James