I think the idea is that you can use it like async/await, except that a function must statically declare which interfaces it is allowed to await on, and the implementations are passed in through an implicit context. I'd be a bit worried that using it widely for capabilities, etc., would just multiply the number of function colors.
> would just multiply the number of function colors.
Would there really be colors?
I mean sure, the caller of an effectful function will either have to handle the effect or become effectful itself, so in this sense effectfulness is infectious.
However, while a function might use the `await` effect, when calling the function you could also just define the effect handler so as to block, instead of defering the task and jumping back to the event loop. In other words, wouldn't this solve the issue of colors? One would simply define all possibly blocking functions as await-effectful. Whether or not they actually await / run asynchronously would be up to the caller.
The problem is, if you're using them for capabilities, it wouldn't just be an 'Await' effect: it would be an 'AwaitDatabase' effect and an 'AwaitFilesystem' effect and an 'AwaitNetwork' effect and an 'AwaitSubprocess' effect and....
And everything working with generic function objects would have to lug around all these effects, unless the language has a very solid 'effect polymorphism' story.
> unless the language has a very solid 'effect polymorphism' story.
That seems to be the premise, yeah. (See also the comment by the Ante author on polymorphism somewhere here in the thread.)
> The problem is, if you're using them for capabilities, it wouldn't just be an 'Await' effect: it would be an 'AwaitDatabase' effect and an 'AwaitFilesystem' effect and an 'AwaitNetwork' effect and an 'AwaitSubprocess' effect and....
I have to admit I will have to think about this a bit. It's already late over here and my brain is no longer working. :)
