Should we disallow unorthodox entry points to functions?

[fgmccabe]

Some formulations of stack switching imply so-called non-standard entry points to functions used to implement suspend-able computations. For example, the fibers proposal uses the idea of event handlers to respond to suspensions and resumptions. It also requires an event handler at the top-level of a function to account for a fiber being created in suspended state.

Whether having such non-standard entry points is a problem that deserves more discussion.

[tlively]

I don't think the top-level event handlers idea (as I understand it) is workable, since event handlers would have to be nested inside blocks to be able to branch anywhere. Top-level handlers that aren't nested inside any blocks wouldn't be able to transfer control to any other code in the function.

A less "unorthodox" way of expressing brand new suspended computations that need to accept one of multiple events would be to provide a mapping of event tags to functions and having the event initially used to resume the computation determine the initial function that gets called. These entry functions can tail call into a shared top-level function if they need to converge on running the same code. This idea has come up in a few places now.

[RossTate]

Yep. This is one of the improvements we were discussing: https://github.com/RossTate/stack-switching/pull/1/files#diff-20ff5146ef4e94eed509778e2c7e38383cbcf3f2cca69dccc6363318bcfe485dR94-R97

[rossberg]

While I agree that an "outside" handler would be less unorthodox then a top-level internal handler, it still seems rather silly. When you create a stack, there is no good reason why you would want to dispatch initially – the same party is normally both choosing the stack's function(s) and resuming it initially, so why wouldn't it just pick the function it wants call up front?

I have no doubt that somebody will come up with a contrived scenario where this could be used, but given the known use cases that seems way too hypothetical to vastly complicate the design for it (instead of expressing such a rare scenario in user space, which is easy enough).

In reality, the need for this is purely an artefact of an inadequate choice of typing regime. I strongly suggest we avoid the underlying problem instead of throwing more accidental complexity at it.

[tlively]

In a design where resumption dispatches on an event tag and it's possible to create a continuation/fiber in a suspended state, there needs to be some kind of dispatch for the initial resumption (or a separate instruction just for that resumption, but that would be worse), so such a design couldn't ignore the problem entirely.

I don't think it's clear at this point that any particular typing regime is more or less adequate than any other typing regime.

[rossberg]

such a design couldn't ignore the problem entirely.

My point exactly. ; )

I don't think it's clear at this point that any particular typing regime is more or less adequate than any other typing regime.

This is not a new problem space at all. We can take cues from inspecting the practical examples we care about (which are mostly fairly standard), as well as plenty of implementations and literature exploring a much wider variety of use cases. That gives a not-so-unclear picture about approaches that are known to work well, some less well, or others that are completely unprecedented and untested.