Desguar all objects to NewObjE, and compile it properly

[nomeata]

if we have to do it for some, lets do it for all! So in desguar, we
now replace ObjE by BlockE { LetD … ; Var D ; LetD o NewObjE },
properly implementing the idea of an object as a bunch of closures.

Object class functions are also desugared here. The class identity is
lost. In light of getting rid of instance-of (#81) that seems fine for
now.

Actors cannot be compiled that way, so they survive untouched (as
ActorE and ActorClassD to be explicit).

The compiler now implements NewObjE so that {x = y} makes x an
alias for y, so that mutable fields stay mutable.

This fixes the semantics of test/run-dfinity/async-obj-mut.as. Yay!

For now, all actor fields have this level of indirection. A further
refinement may restrict that treatment only to mutable fields.

Small wart: If the compiler finds that a mutable variable is not
captured by a function, it will allocate it on the stack. If such a
variable is put in NewObjE, the content will be put in a new box. This
is fine for the output of the desguaring: If it was not captured, the
local x is not referenced after the object has been created.
But this is shaky ground, and may need to be revisited (probably by
beefing up the AllocHow algorithm that determines whether to
heap-allocate a variable).

[crusso]

I was at first worried that the desugaring of objects expressions to blocks ending in let this = NewObj ... didn't follow the same declaration order as in the interpreter (which promises 'this' first) but it turns out it doesn't matter as you can't shadow fields names or this by virtue of type-checking. I take the same liberty in the async translation, so you're in bad company;-> If we ever change our mind to allow shadowing of 'this' (or perhaps curtailing type annotations on this) then we would be in trouble so it might be safer if we both here and in async(opt).ml elaborated to { this = {fields;NewObj(...);} }.

Why can't you apply the same elaboration to actor expressions? Or is this just a todo?

[crusso]

Is this just the value represtion of type Ref ? Why not call it that and add a comment to disambiguate from Dfn Reference

[crusso]

Oh no, this is something else - MutBox represents a Ref, right?

[nomeata]

MutBox is for mutable local variables. It is like ObjInd (or Some) in terms of heap layout. But MutBox should never have to be serialized when sending messages, hence I keep them separate here.

[crusso]

So is it for promises stored in fields? I think I need to study the compiler a bit more, but go ahead and merge. I'm having trouble finding a button to actually approve the PR...

[nomeata]

Actually, in light of let x = e and let x = e; x not being the same thing, as you discovered recently, I will have to fix that here.

{ this = {fields;NewObj(...);}

I am not sure I follow. Can you give an example of what could go wrong?

Why can't you apply the same elaboration to actor expressions? Or is this just a todo?

Not a TODO, a “don’t know how to do”. Moving the bindings out of actor { … } would move their execution from inside the new actor to outside it. Or, put differently, actor { … } can’t capture non-sharable things, so we can’t move non-sharable things out.

This is very dissatisfying, but I don't have a good idea here.

[crusso]

I was thinking if we allowed:
new this { this = 1;}
Then the translation:
{ let this = 1; let this = newobj [this,this]; this}
wouldn't work; but
{this = { this = 1; newobj [this,this] }
might.

That's is indeed a bummer about actors. I'm pretty sure I break the semantics if an actor expression does an await in its body, but don't if it doesn't. Perhaps that's a clue to how we prevent the breakage.

[nomeata]

Thanks for elaborating! Yeah, that might work… but as long as we don’t allow this, we don't have to bother, I think. (And it seems to be good to not allow this).

That's is indeed a bummer about actors. I'm pretty sure I break the semantics if an actor expression does an await in its body, but don't if it doesn't.

await in actor bodies should be ruled out since 3ef5ae1. You should not have to even look in to them when doing the translation.

[crusso]

That's good, but probably not quite true since the actor methods themselves may need rewriting internally. But nice!

[crusso]

You have my approval to merge ..