Desugar expressions (part 2)

[chriso]

This is part 2 of #44, where we decompose expressions that contain function calls.

[achille-roussel]

I didn't realize this earlier but we may have to try to perserve type names because those will be visible to the program via reflect.TypeOf(...).Name(), by changing it we might break some programs.

It gets tricky if the type is used in a struct field etc... I know it's difficult due to the shadowing rules, we'll have to be creative :)

[chriso]

Ok, let's look at this in a follow-up.

[chriso]

We hoist the type decls because the dispatch control flow means that their definition might be moved into a new scope and not be accessible to subsequent statements.

What we could do is not hoist type decls to the function prologue, and not rename them (since we don't have to worry about name clashes at the top-level anymore), and instead handle type decls when building the dispatch control flow. Since types can be shadowed within the same block, we can't hoist type decls into a "block prologue". Maybe when introducing new dispatch scopes we'll need to copy applicable type decls into that inner scope?

[achille-roussel]

Yep, we have options. Declaring the original types in places where they were supposed to exist and then doing late type conversion could work well 👍 If I remember correctly Go accepts type conversions when the memory layouts are compatible.