Zig's new I/O: function coloring is inevitable?

Post by woodruffw » Mon, Jul 14, 2025, 4:59 PM UTC

throwawaymaths wrote: post #60

woodruffw wrote: post #56

Earlier quoted context omitted.

It also has the I/O effect. You don’t need to call or make use of an effect to be “tainted” by it; it just needs to be in the closure (or whatever scope is relevant in the language). Intuitively: if you mark a function as async, it doesn’t stop being async “colored” just because you don’t actually perform any async operations in it. This is the same thing.

you might be talking about stackless coroutines, which are currently not part of zig, in which case, yes, the compiler might [0] have to instantiate different functions under the hood for the stackless-coro and the non-stackless-coro cases, with some mechanism to drop in an executor at the boundaries. until then its really hard to claim that the functions are colored. [0] But even in that case there's not really colo…

Post by woodruffw » Mon, Jul 14, 2025, 5:47 PM UTC

throwawaymaths wrote: post #62

woodruffw wrote: post #61

Earlier quoted context omitted.

No, I really just mean from a PLT perspective. The sync/async implementation used under the hood doesn't matter; what matters is that an `Io` in the closure is a token type for communicating effects. No instantiated or enclosed token; no effects. People seem to be really defensive about this, like it's a bad thing. It isn't! It's arguably a significantly cleaner way to handle what people confusingly call "coloring."…

1. the original author of the function coloring post wad not exactly a theorist so if you're applying some other idea of what coloring is, then you're muddying the waters. 2. here's what i have to say about your idea of what coloring is: That's all fine and good in theory , but in practice it makes no difference, at the user level, or at the compiler level.

Post by throwawaymaths » Mon, Jul 14, 2025, 7:34 PM UTC

woodruffw wrote: post #63

throwawaymaths wrote: post #62

Earlier quoted context omitted.

1. the original author of the function coloring post wad not exactly a theorist so if you're applying some other idea of what coloring is, then you're muddying the waters. 2. here's what i have to say about your idea of what coloring is: That's all fine and good in theory , but in practice it makes no difference, at the user level, or at the compiler level.

I don’t know anything about the original author, but I do know what function coloring is . It’s a way to describe effects. An effect is a function color. > That's all fine and good in theory, but in practice it makes no difference, at the user level, or at the compiler level Every example given so far shows Io’s virality, so I don’t know how you can assert how it doesn’t make a difference. The entire point of the des…

Post by dwattttt » Mon, Jul 14, 2025, 9:34 PM UTC

SkiFire13 wrote: post #58

dwattttt wrote: post #54

Earlier quoted context omitted.

> the only solution is to make everything of one kind That's not really the case. All you really need is a way to run async code from a sync function; "keep doing this async thing until it's done" is the primitive you need, and some languages/runtimes offer this.

Going by that reasoning then Rust solved the colored function problem too: when calling an `async` function from a sync one use `block_on`, while when calling a sync blocking function from an `async` one use `spawn_blocking`, but somehow people are not happy with this.

Post by Dylan16807 » Mon, Jul 14, 2025, 11:59 PM UTC

tcfhgj wrote: post #11

kristoff_it wrote: post #5

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then. fn foo(db: *Db) !void { ... } fn bar() !void { ... } Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to…

> The virality of async await is that once you mark a function async, then you can only call it from another async function Rust calling async function in non-async function: ... // Create the runtime let rt = Runtime::new().unwrap(); // Get a handle from this runtime let handle = rt.handle(); // Execute the future, blocking the current thread until completion handle.block_on(async { println!("hello"); }); https://do…