[Grace-core] initialisation & checking

[James Noble]

> Yes, indeed.    It seems to me that since we want the REPL and Modules to behave differently from immutable objects, we ought to have two different constructs.

?? I don't think we want modules to behave "differently"
also I think we may be using the word "immutable" differently.

> (1) Immutable objects, which are created atomically and can't be changed once a reference to them has been made available. (I think that this is the OCaml semantics, more or less.)    We could even make the "no executable code"  and "no-self reference during creation" restrictions apply only to immutable objects. 

there is a difference between an changing variables in an object and changing that object's structure.
Most class-based languages you can't change an object's structure post-creation, 
and that was also true of self -  in both cases with the exception of reflective programming - 
but I think we must exclude reflection from our discussion here. 

Our "main" story shouldn't involve reflection, and we certainly shouldn't expect to have to teach reflection in CS1 or CS2 (indeed, I hope that's an advantage Grace will have vis-a-vis Ruby in particular)

> (2) Modules and the RPEL, in which arbitrary executable code can be executed at the time that it is encountered, and in which later declarations of methods can change the meaning of executable code, and in which later variable and constant declarations can change the bindings seen by that code.  (I think that this is more or less the JavaScript semantics, but I don't know whether Javascript has lexical bindings.) 

I mean to get a couple of JS e-books --- my general line is that JS isn't any kind of good model.
I still think this is mixing structural and base-level mutation issues.

> What about ordinary mutable objects?   We could choose either the OCaml semantics or the JavaScript semantics.  There are arguments both ways.

In my head, ordinary objects may be mutable - in that they may contain variables - 
but their structure should be fixed post creation up to quite powerful reflexion. 

> Kim, your discussion of the "prepare" phase of object creation is I think broadly similar to what I wrote in my MASPEGHI submission about "2-phase" object creation, based on discussion with James.   (You probably haven't had a chance to read that yet.)  I find this encouraging, because we are all coming to see the semantics in the same light.

right. and yes I really do think we are converging.

>    My objection to the 2-phase semantics, apart form the complexity, is that the meaning of exp in "inherits exp" isn't compositional.   

but then the meaning of x.m in x.m:=3 isn't "compositional" either.

> Kim, you ask at the end of your message: why can't we just do what Java or Scala do?   I want to be _better_ than Java or Scala.

me too! 

> We set out to do something around object initialization, including initialization of inherited state, that was much more straightforward than either Java or Smalltalk — this is neither.   We considered a proposal very like Java— I wrote it up as the Templates are not objects proposal.   It has all of the problems of Java — especially, encouraging programmers to use a language primitive (new) rather than a method to create objects, which exposes an implementation secret to the client. 

well Dart lets programmers redirect "new" to anything they want - reintroducing that secret.
But Andrew is right, doing things that way around seems backwards! 

But I also argue that a 2-phase, "inherits exp" design is more straightforward than Java or Smalltalk (perhaps a little more complex than O'CAML, depending on how you measure the complexity of restricting things).  Certainly it is much simpler already than Java, with its flow-sensitive checking, multiple overloaded constructors, calls to self- and super-constructors.

regarding Smalltalk, it's late and I've lost my jetlag and gained a cold - so ee fig 16.5 - 
looking at the Blue book reminded me how beautiful it is,
and the hope that we'd be able to produce something like that for Grace

J


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.pdf
Type: application/pdf
Size: 210892 bytes
Desc: not available
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130430/c10e90b0/attachment-0001.pdf>