But this gets back to what I was saying about generalization - the way I would implement what you're talking about is with coroutines and dynamic scoping. I'm still missing how AE is more general and not something you implement on top of other building blocks.
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.
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.
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. :)
For example, a function annotated with say `query_db(): User can Datebase` means the function can call database and the caller must provide a `Database` handler to call the `query_db`.
The constraint of what can do and not is pretty popular in other programming fields, most notably, NextJS. A server component CANNOT use client feature and a client component CANNOt access server db.