Function bind about function-references

[rossberg]

Are you referring to the bullet that defines the type of the instruction? Sorry, there actually was a typo there, the immediate should have been $t', the resulting function type. With that fixed, the instruction takes a ref to a function of type $t and its first n arguments and returns another reference to a function of type $t' with the respectively shortened parameter type list.

There is no restriction on the life time of the closure.

[fgmccabe]

Thanks for the clarification. The lifetime question essentially creates an entanglement with the gc proposal. IMO, I wonder if it isn't time to 'bite the bullet' and actually implement managed memory.

…

On Wed, Mar 13, 2019 at 10:33 AM Andreas Rossberg ***@***.***> wrote: Are you referring to the bullet that defines the type of the instruction? Sorry, there actually was a typo there, the immediate should have been $t', the resulting function type. With that fixed, the instruction takes a ref to a function of type $t and its first n arguments and returns another reference to a function of type $t' with the respectively shortened parameter type list. There is no restriction on the life time of the closure. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAL0GAfeSVB1YKJQRV02a3anlxONFluks5vWTZVgaJpZM4btx2G> .

-- Francis McCabe SWE

[rossberg]

The motivation here was that functions in Wasm are closures already (over their module instance). And since all current production engines allow dynamic module instantiation they already have to deal with the same life time issues for the resulting closures. This may be via a GC or via reference counting. In a way, func.bind would just piggyback on the existing mechanism (which hopefully is efficient enough for this use case).

[fgmccabe]

That 'closing over the machine' that is currently done would tie the lifetime of a closure to the lifetime of the instance. What is needed is to be able to relate the lifetime of a closure to other elements within an instance -- i.e., GC of closures.

[rossberg]

The life times of a module instance and that of one of its functions are not necessarily the same, even now, although one typically keeps the other alive (which theoretically can happen either direction). At least in principle, individual functions can already be dead while their module is still in use.

In general, we'll have a number of objects in Wasm that require dynamic life time management by the engine. Exception packages are another such example.

I didn't understand what you mean by closing over the "machine".

[rossberg]

Func.bind never had consensus and has been dropped from the proposal.