[Grace-core] initialisation & checking

[James Noble]

> Yes, I agree that this is a serious problem.  The root cause is that we have been using "top level code" in object constructors to do two things.
> 
> (1) In the REPL, and in Modules, it's just code that should  be executed asap.  In the REPL in particular, we want it executed before the object is completely created, which ca't happen until the END of the object constructor is reached.

in some cases at least, this is the case for code in objects generally.
Certainly for debugging, its great to just dump some code in there to print or something.

> (2) In inherited objects, we want to delay the execution of the top level code until after all of the sub-objects have been created, since the sub-objects might change the meaning of any of that code.

right. I now think this *is* a special case, we don't support it, and we probably should.
But it's really only required for framework builders, not even simple inheritance
for modelling (I think).

> There desires are fundamentally in conflict.   We can eliminate that conflict by banning the offending code.  Other proposals are welcome!

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

> If we do ban executable code in object constructors, then we would need to make modules and "scripts" something else.    The obvious choice is methods, but I have to admit that I really dislike the idea of a "main method" as in Java — the name "main" makes it sounds as though that method should be important, whereas in fact it's unimportant.

right. so let's not do that...

> Michael is also right that our model for doing procedures-first required the incremental growth of objects by adding methods, which could be requested as soon as they were added, even though the object is incomplete.  It does seem a shame to loose that — but I am more concerned with having a sensible semantics for objects than being able to use methods like procedures.

whether the REPL is a module or a method or whatever, it's going to be special:
it has to run when it is in some sense "incomplete".
But I think it always makes sense to build the "structure" of the whole object,
including method, before doing initialisation so I don't see this as a problem. 
Forbidding inline code is a problem. 

Again - surprisingly perhaps - I'd like clear, straightforward explicable semantics,
first of all - something to tell the children as Andrew puts it.  If we want to rule 
out programs, we can do that with a dialect. I don't see that a dynamic variable not
initialised error as worse than a dynamic no such request error - a type system could
rule that out, but that shouldn't be part of the fabric of the language.

James