Interpreter issues with func.bind

[titzer]

Related to #11 and #27.

Because there is no type annotation for type of the incoming function argument to func.bind, the runtime representation of a function must include the signature of the function in order for the interpreter to compute how many stack arguments are bound. It must also annotate the new closure with the signature for future func.bind instructions.

It gets hairier with subtyping. Here, the interpreter must compute the new signature from the signature of the incoming function, since it may differ from the signature specified in the immediate (i.e. be a subtype), and then store that signature on the newly bound closure, since that amounts to RTT that might be used when storing the function into a table.

[rossberg]

Doesn't a function need to contain its signature anyway? How else would you implement call_indirect -- or in the future, casts on functions?

[titzer]

For call_indirect, each table entry stores a signature id (call tag). Only table.set needs to look at a funcref value's signature in order to derive a signature id. For unbound functions, this can be computed from the code pointer of the function alone (up until we have type imports, in which case, it can be computed from the code pointer and the instance). For bound functions, the closure object can contain the number of bound arguments, thus the signature can be computed lazily from the function pointer and the closure object.

Related to #27, this is another example of statically derivable information becoming dynamic information.

I think it would be better to add an additional u32 immediate to func.bind which is the number of arguments bound. Even better would be a bitmask of which arguments are bound so that programs could do more than just left-to-right binding.

[rossberg]

Func.bind has been dropped from the proposal.