[Grace-core] Notes on Grace

[Marco Servetto]

The problem is really an hard one.
and there forces that pulls in different directions:

1a) standard semantic/expressivity
1b) intuitive semantic

2a) language as library helper
2b) language as helper for the final programmer.


let me repeat the Kim mail focusing on this points:

>1.  Reactions from PLDesign
>Most of the feedback I got about Grace at the meeting was concern about the complexity of supporting
>both object and class inheritance.
>they generally thought one of those two notions was sufficient
that is,  we should choose between 1a and 1b


>and weighed in strongly for inheritance with classes as what most people want.
That is the point: how can we support the standard, involved, semantic
of inheritance and an intuitive one at the same time? structural
typing works best with object based stuff, that is, everyone can
create a foolike
stuff, while with class based languages I need a permission/capability
to create a foolike stuff
(the fact that in java you can extends an interface without any
permission from the interface author is somehow a failure of nominal
typing)

> We could still define objects and object factories, but they would not be inheritable.
that is about 2: do we want a language more usable for writing little
programs where the primitive of the language are something that is
used when the programmer want to reach its final goal,
(and I think Grace is much more oriented in this direction)
or we want a language where the primitive are useful to build up
further layers of abstraction, (dialects? factories?)
and is easy to abstract over and over to finally create a library that
helps to solve the problem?


>2.  Delegation instead of prototypes
>leaning toward a delegation interpretation.
And... why you two are doing so? I feel is for a 1a reason, that is,
is what is done in the past.

>3. Abstract classes and classes
> We need to have abstract classes in Grace.
I think we need abstract *methods*
the fact is that conventionally abstract classes are the way to have
abstract methods in Java,
so we are simply conditioned by  1a.
We want abstract methods, and in a minimal setting, an object with an
abstract method, would be an abstract object.

>4.  Initialization
>On a slightly different issue, Andrew suggests that we distinguish between creation & initialization phases.
I can not help, but I continue to see no problem in simply denying any
use of this/self in object initializes.
This, together with full object inheritance (we enrich the old objects
with new attributes) would make
a simple (non conventional) semantic; that I think is quite easy to explain.
If one want to forbid further object extensions, an object can be "final"

def o1 = object {.../*o1stuff*/...}
def o2 = object { extends o1.../*o2stuff*/...}

is rougly equivalent to
def o1 = object {.../*o1stuff*/.../*o2stuff*/...}
def o2 = o1

and
def o1 = object {.../*o1stuff*/...}
def o2 = final object { extends o1.../*o2stuff*/...}


is rougly equivalent to
def o1 = final object {.../*o1stuff*/.../*o2stuff*/...}
def o2 = o1

This promote an healthy division between code for use and code for reuse:

Adam write a object and an A factory for it, It also put some abstract
method in.
Bob reuse the code of Adam: write a final object that customize the
methods of A like objects.
If Charles tries to reuse from Bob, that is intended to be final code,
he fail, he have to use directly the reusable library of Adam.
We could even impose that all the objects are either abstract or
final, but may be this is too strong.

The proposed philosophy  goes strongly in the directions of 1b and 2b.

- I see no reason to use self in initializes in this philosophy.
- It is far simpler that anything else we have.
- It supports traits and mixins as methods that enrich a parameter object.
   method traitFoo(... x ...) object{extends x .../*new stuff*/....  }
   def a= final object{ extends traitFoo(traitBar(traitBeer(object{})))}

Any thought?