Various backend changes

[nomeata]

Various improvements in the backend.

@crusso, does 5cb507d look reasonable, or is there more bookkeeping to get a valid con_env?

[crusso]

As I mentioned on Slack, I think you'll also need to extended the con_env when you go under a type binder, eg. to correcty compile func X<T<:(Int,Bool)>(x:T) : Int { x.1; }. (In order to promote the type of x you'll need to have access to T and its bound.

[nomeata]

Right, I have an example that fails because of this. I just need to find out how to correctly extend a con_env with a typ_binds.

[crusso]

When you say avoid allocating closures to you mean for functions that are are not used at all or just not in higher-order ways?

[crusso]

Just look at check-ir - the typ_binds should be open already and the constructor names are stored as a note on the annotated typ_bind.

[nomeata]

Uh, that’s round-about. Shouldn't the IR already contain the stamped constructor names in an Ir.typ_bind that is different from the (less helpful) Type.typ_bind (which has just the name, not the stamp)?

[nomeata]

When you say avoid allocating closures to you mean for functions that are are not used at all or just not in higher-order ways?

The latter.

[crusso]

Yeah, the encoding is a bit funky and it would be cleaner to just have the function type and list of constructors used to open it separately. But this was the quickest to port from syntax.

[crusso]

I can open an issue to rationalize Ir.FuncD, if you like

[nomeata]

I can open an issue to rationalize Ir.FuncD, if you like

I’d appreciate that. I think add_typ_binds in compile.ml ought to be much simpler :-)

[crusso]

Will open the issue. Otherwise LGTM.

[crusso]

LGTM

[crusso]

See issue #154