9 ms·
> It has the I/O effect it does not, because it can take a vtable that does not call i/o concretely: const VTable = struct { f: &fn (*VTable) void,
by throwawaymaths 1y ago
> It has the I/O effect
it does not, because it can take a vtable that does not call i/o
concretely:
const VTable = struct {
f: &fn (*VTable) void,
};
const A = struct {
io: IO,
v: VTable = .{ .f = &A.uses_io },
fn uses_io(this: *VTable) void {
const self: *A = @fieldParentPtr(.v, this);
self.io.some_io_fn(...);
}
};
const B = struct{v: VTable = .{.f = &void_fn}};
fn void_fn(_: *VTable) void {}
\\ WHAT IS THE COLOR OF THIS FUNCTION?
pub fn calls_vtable(v: VTable) {
v.f()
}
- woodruffw 1y agoIt 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.
- deleted 1y ago[deleted]
- throwawaymaths 1y agoyou 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 coloring because if you provide a single io implementation there won't be different functions, even at the compiled level.
- woodruffw 1y agoNo, 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." But that doesn't make it not "coloring," because coloring is about effects and vitality, not about keywords and syntax.
- throwawaymaths 1y ago1. 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.
- woodruffw 1y agoI 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 design appears (reasonably) to be to introduce a token object that conveys an effect, rather than requiring a runtime to intermediate that effect. Again, none of this is bad. Effect typing is cool. But it is, by definition, a way to color a function. (Maybe the confusion here stems from the fact that languages like Go appear to have it “both ways” without coloring. Go is able to do that because it has an intrusive runtime that intermediates asynchronous events. Zig can’t do the same thing without making the same compromises as Go vis a vis FFI performance and ABI compatibility.)
- throwawaymaths 1y agoThe vtable example is nonviral.
- woodruffw 1y agoI don’t see how that can be the case, given that Io is in the closure. Anything that wants to do I/O needs that token; that’s what virality is.
- throwawaymaths 1y ago