Fix/issue129

[crusso]

… issue 129); fix typing error message; refactor anon identifier creation.

Fix for issue 129

The declaration syntax
new/actor/object/shared id? =? {...};
desugars to let binding (LetD)
let id? = new/actor/object/shared id? =? (...) ;
which, unfortunately, has unit type ().
One would reasonably expect this to desugar to
a declaration expression (ExpD):
new/actor/object/shared id? =? {...}.

It might make more sense to only do the desugaring for declarations of the form
new/actor/object/shared x = { } (with an explicit =) but that would break current test tests\run\actor.as;

[rossberg]

Yeah, this is even more hacky now. I don't like that it now makes a difference for typing whether you give it a recursive name. But I suppose it's okay as a temporary fix.

I'm a bit confused about the gigantic set of commits in this PR, though. Something seems messed up. Can you rebase your change on master?

Btw, when you cite an issue or PR number as #129 then GitHub will automatically convert it into a link.

[crusso]

I've squashed and merged it instead of rebasing. I think the problem was because I branched of check_ir but then squashed check_ir before merging.

[nomeata]

Doing desugaring in the Parser causes confusing type error messages if the type checker wants to pretty print expressions, i.e. code that is different from what the user wrote.
I know it is tedious to have a large source AST that needs to be typechecked, but it is the proper thing to do. Desguaring should happen in, well, desguar.

[rossberg]

I'm fine with trivial desugarings like this being done in the parser. Don't think we want to print ASTs in error messages anyway, that's what source locations are for.

[nomeata]

But even if we don’t print actual AST fragments, there is still a risk to say “in a let-binding at …” where there isn’t a let binding there, but rather an object declaration.

But not a big deal and we have more important things to do, so I will not press this issue.