[Grace-core] Dialect Design Proposal

[Kim Bruce]

It seems clear to me that if we are to support stateful modules, then the default should be that there is only one that is shared.  (Given that default, we could clearly program to get separate copies of state if we wanted them.)

We seem to be at a bit of a standoff here with strong differences in what is desired for the language.  I believe that it is essential that we support the standard semantics for classes and inheritance -- in particular that messages to self in the construction of an object refer to that object and not to some superclass object.  When I teach this material I will use that semantics, and I believe that we will have even less chance of a buy-in from instructors if we don't support that semantics.

As Andrew has pointed out, inheritance from objects has issues.  No doubt this explains why it generally doesn't show up in mainstream languages.  James points out below that this is supported by Self and Javascript, but they are prototype based.  At this point, I'm confused enough that I'm not even sure any more what the intended semantics is for inheritance from objects.  Is it sharing (essentially some variant of delegation) or does it involve some sort of implicit clone (though I'm not sure what kind)?  Perhaps someone can point me to an e-mail that proposes exactly what it should be.

I'm getting frustrated enough to suggest maybe we should support both of these semantics by different syntax.  One instructor could choose working with classes and classical inheritance, while another could choose working with objects and some sort of delegation (perhaps using "sharing" instead of "inherits").  Both clearly have some uses, and neither seems easily definable from the other (and I fear what error messages would look like if we tried to define them that way).

I'm not happy with this solution, but I'd be even more unhappy to throw out the standard semantics of inheritance.  Andrew would be very unhappy if we threw out inheritance from objects.  Is there anything that might bridge the gap that doesn't make everything worse?

Kim



On Nov 26, 2012, at 2:34 AM, James Noble wrote:

>> There may be reasons to do this, but it is something new.  Up until now, we have said that files = modules have an implicit
>> 
>> 	def <filename> = object { … } 
>> 
>> wrapped around them, which means that each time I import it, I get a new object.
> 
> I'm pretty sure you've only got a module once per program.
> Otherwise, if say two different modules import module "A" - surely they should share the same module-object?
> It's hard to see how you could communicate between modules otherwise.
> 
>> Implementing restriction using a checker seems OK, but  it seems to me that we need a standard one, and a standard annotation (perhaps "is local") for the checker to look for.
> 
> yes, and that's fine by me. 
> 
>> The discussion about not being able to inherit from objects convinces me that not being able to inherit from objects is ungraceful.   Eash new workaround that we invent to get around this wrong-headed restriction makes the restriction itself look more like a wart than a patch.   In particular, it's worse than the disease it was supposed to cure.
> 
> in the specific case: 
> 
> for modules, the primary question is whether they are generative or not - 
> are modules singleton objects, or generators of objects - basically classes that produce multiple objects.
> If they're classes, presumably we could make them type-generic too.
> 
> The alternative is that modules themselves create singleton objects, but those objects can include generative entities - classes.
> 
> 
> in the general case: the only languages I know of where you can "inherit from objects" are the prototype based ones like Self and JavaScript.  Both those two - in practice - have arguably larger warts in their inheritance systems that the current Grace design.
> We may well be stuck in a local maximum in the design space, but the other approaches I'm aware of have problems too.
> We could e.g. go to a trait based design, but that would probably be *more* stratified, with objects build out of traits. 
> rather than letting programmers inherit from objects directly. 
> 
> I understand Michael has a version of the dialect & module proposal going.
> For now, I'd like to work with that and see how that goes before heading back towards inheritance again.
> 
> James
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core