[Grace-core] initialisation & checking

[Andrew P. Black]

On 27 Apr 2013, at 22:26, James Noble wrote:

> banning the offending code isn't enough.
> Some way of doing the right thing would be nice!

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.

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

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

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

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

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

	Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130428/9f8b72fd/attachment.html>