functions -> state machines (aka async functions / supsend functions / continuations)

[alex-s168]

how this should work in theory

allow functions to be marked as async, which makes the compiler convert the function to a struct which contains all the locals and temporaries, and a step function which takes the current state and returns either a new state or the return value.

this allows for many cool things:

• yield(): lazy and/or infinite collections
• lightweight threads: by scheduling for example 32 function calls on a pool of 4 threads
• async I/O obviously
• pause a function while some other important event is happening (can also be achieved by other ways)

problems

how to properly integrate that with the existing type system?

[andrew-johnson-4]

Functions are proofs, not always stack functions. This has been a design goal since the start.

How it works

let the-transform( dependency1: KnownProperties1, dependency2: KnownProperties2 ) : ResultProperties = (
   transform-step-1( dependency1, other-stuff-1 );
   transform-step-2( dependency2, other-stuff-2 );
   result
);

When designing non-traditional functions think:

• what do I know before the transformation
• what do I know after the transformation
• how do I get from A to B

The type system already works with this design in mind, however the backend doesn't really handle this abstraction cleanly. It still expects mostly traditional functions. However, the Fragment model is a strong backbone to build on, it just currently is in an unfortunate state.

[andrew-johnson-4]

Also see early design docs for chain / apply which abstracts this even a little more:

• Clarify rules for default Apply vs Chain behavior and Explicit vs Implicit arguments #77