Modal components

This is a link to tom7's amazing PhD: http://tom7.org/papers/modal-types-for-mobile-code.pdf

As the PhD says, it's about "modal types for mobile code". We see it as an alternative to the threading model provided by component model's thread.spawn.

Importantly, while modal types can be trivially used for threads, they can also be extended beyond threads, into the areas of heterogeneous computing. This includes, for example:

• An async-signal safety model, for WASI users who really want to shoot themselves in the foot, like ourselves.
• Possible other cases like bridging across the client-server model. Not that anyone would ever actually use this, but it's fun to talk/think about.

So, the main use case for modal components is to provide threads without providing threads. It's basically a generic API for providing things that work like threads. Because, whether you like it or not, threads are mobile code. (With shared-ish memory, but we can just extend the model for that, it doesn't have to be shared-nothing.) But it can also do other things. In fact, you could even use the same modal component API for system-equivalent subprocesses, like popen and stuff.

Start by reading the linked paper on modal types for mobile code and compare its model with the component model's thread.spawn. Then examine the proposed use cases for WASI async-signal safety, client-server bridging, and subprocess-like behavior. Done would require an agreed design for a generic modal component API, but the issue does not define one.