Zig's new plan for asynchronous programs
171–180 of 274 posts
Re: Zig's new plan for asynchronous programs
#172Earlier quoted context omitted.
> Function coloring is specifically about requiring syntax for a function, eg. the async keyword. Someone should tell the inventor of the phrase, because they don't mention the async keyword at all[1]. As-written, function coloring is about callbacks (since that's semantic mechanism that JavaScript happens to pick for their asynchronous model). Function coloring is just an informal way to describe encoding a function…
They specifically called it out as a syntactical issue, where the issue was based around the requirement to have the 'red' or 'blue' keyword. The section on "2. The way you call a function depends on its color." makes this pretty explicit... 2. The way you call a function depends on its color. Imagine a “blue call” syntax and a “red call” syntax. Something like: doSomethingAzure()blue; doSomethingCarnelian()red; When…
I don’t think so? The implication is that it’s a callback, which of course is going to require another call to realize the evaluation. But it’s not inherently another keyword; the keyword is just sugar for deferred evaluation.
Re: Zig's new plan for asynchronous programs
#173I think this design is very reasonable. However, I find Zig's explanation of it pretty confusing: they've taken pains to emphasize that it solves the function coloring problem, which it doesn't: it pushes I/O into an effect type, which essentially behaves as a token that callers need to retain. This is a form of coloring, albeit one that's much more ergonomic. (To my understanding this is pretty similar to how Go sol…
Agreed. the Haskeller in me screams "You've just implemented the IO monad without language support".
i mean not really? it absolutely does nothing to segregate stateful impurity into a type theoretically stateless token
Re: Zig's new plan for asynchronous programs
#174Earlier quoted context omitted.
Yes.
Can you explain for those of us less familiar with Haskell (and monads in general)?
Let's see if I can do it without going too far off the deep end. I think your description of the _IO type_ as "a description of how to carry out I/O that is performed by a separate system" is quite fair. But that is a property of the IO type, not of monads. A monad in programming is often thought of as a type constructor M (that takes and returns a type), along with some functions that satisfy certain conditions (called the "monad laws").
The `IO` type is a type constructor of one argument (a type), and returns a type: we say that it has kind `Type -> Type`, using the word "kind" to mean something like "the 'type' of a type". (I would also think of the Zig function `std.ArrayList` as a type constructor, in case that's correct and useful to you.) `IO String` is the type of a potentially side-effecting computation that produces a `String`, which can be fed to other `IO`-using functions. `readLine` is an example of a value that has this type.
The Haskell function arrow `(->)` is also a type constructor, but of two arguments. If you provide `(->)` with two types `a` and `b`, you get the type of functions from `a` to `b`:
`(->)` has kind `Type -> Type -> Type`.
`(->) Char` has kind `Type -> Type`.
`(->) Char Bool` has kind `Type`. It is more often written `Char -> Bool`. `isUpper` is an example of a value that has this type.
The partially-applied type constructor `(->) r`, read as the "type constructor for functions that accept `r`", is of the same kind as `IO`: `Type -> Type`. It also turns out that you can implement the functions required by the monad interface for `(->) r` in a way that satisfies the necessary conditions to call it a monad, and this is often called the "reader monad". Using the monad interface with this type constructor results in code that "automatically" passes a value to the first argument of functions being used in the computation. This sometimes gets used to pass around a configuration structure between a number of functions, without having to write that plumbing by hand. Using the monad interface with the `IO` type results in the construction of larger side-effecting computations. There are many other monads, and the payoff of naming the "monad" concept in a language like Haskell is that you can write functions which work over values in _any_ monad, regardless of which specific one it is.
I tried to keep this brief-ish but I wasn't sure which parts needed explanation, and I didn't want to pull on all the threads and make a giant essay that nobody will read. I hope it's useful to you. If you want clarification, please let me know.
Re: Zig's new plan for asynchronous programs
#175Earlier quoted context omitted.
Yes.
Can you explain for those of us less familiar with Haskell (and monads in general)?
I see I’ve been beaten to the punch, but I’ll post my try anyway.
Your comment about IO handled by an external system In response to a comment about the more general concept of a monad is what they are, somewhat abruptly referring to in the above two comments.
The IO monad in Haskell is somewhat ‘magical’ in that it encapsulates a particular monad instance that encodes computational actions which Haskell defers to an external system to execute. Haskell chose to encode this using a monadic structure.
To be a bit more particular:
The Reader monad is the Haskell Monad instance for what can generically be called an ‘environment’ monad. It is the pattern of using monadic structure to encapsulate the idea of a calling context and then taking functions that do not take a Context variable and using the encapsulating Monad to provide the context for usage within that function that needs it.
Based on your streams in the new system I don’t see a monad, mostly because the Reader instance would basically pipe the IO parameter through functions for you and Zig requires explicit passage of the IO (unless you set a global variable as IO but that’s not a monad, that’s just global state) to each function that uses it.
From my perspective Zig’s IO looks to be more akin to a passed effect token outside the type system ‘proper’ that remains compile time checked by special case.
Re: Zig's new plan for asynchronous programs
#176Earlier quoted context omitted.
how do you "fail to obtain the token"?
The token guards a fallible resource (I/O). You can (temporarily or permanently) fail to obtain it for any reason that would affect the underlying I/O.
the io isnt a single resource? it's a module grouping together a pile of code. and you can swap out implementations. the io modules should be responsible for handing out many failable resources, and synchronization is going to be up to the io module code, and thats whether or not it's globalized or passed.
Re: Zig's new plan for asynchronous programs
#177One thing the old Zig async/await system theoretically allowed me to do, which I'm not certain how to accomplish with this new io system without manually implementing it myself, is suspend/resume. Where you could suspend the frame of a function and resume it later. I've held off on taking a stab at OS dev in Zig because I was really, really hoping I could take advantage of that neat feature: configure a device or sub…
what's the point of implementing cooperative "multithreading" (coroutines) with preemptive one (async)?
There was this beautiful little time period where async/await was basically just that: resumable functions. I abused it to implement generators.
Re: Zig's new plan for asynchronous programs
#178Earlier quoted context omitted.
Can you explain for those of us less familiar with Haskell (and monads in general)?
Let's see if I can do it without going too far off the deep end. I think your description of the _IO type_ as "a description of how to carry out I/O that is performed by a separate system" is quite fair. But that is a property of the IO type, not of monads. A monad in programming is often thought of as a type constructor M (that takes and returns a type), along with some functions that satisfy certain conditions (cal…
This is pretty concise, but is still really technical. That aside, I think the actual bone of contention is that Zig’s IO is not a Reader-esque structure. The talks and articles I’ve read indicate that function needing the IO ‘context’ must be passed said context as an argument. Excepting using a global variable to make it available everywhere, but as I said in a sibling comment, that’s just global state not a monad.
In a manner of speaking, Zig created the IO monad without the monad (which is basically just an effect token disconnected from the type system). Zig’s new mechanism take a large chunk of ‘side-effects’ and encapsulates them in a distinct and unique interface. This allows for a similar segregation of ‘pure’ and ‘side-effecting’ computations that logically unlined Haskell’s usage of IO. Zig however lacks the language/type system level support for syntactically and semantically using IO as an inescapable Monad instance. So, while the side effects are segregated via the IO parameter ‘token’ requirement they are still computed as with all Zig code. Finally, because Zig’s IO is not a special case of Monad there is no restriction on taking IO requiring results of a function and using them as ‘pure’ values.
Re: Zig's new plan for asynchronous programs
#179Overall this article is accurate and well-researched. Thanks to Daroc Alden for due diligence. Here are a couple of minor corrections: > When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away. While this is a legal implementation strategy, this is not what std.Io.Threaded does. By default, it will use a configurably sized th…
Daroc here — I've gone ahead and applied two corrections to the article based on this comment. If you want to be sure that feedback or corrections reach us in the future (and not, as in this case, because I'm reading HN when I should be getting ready for bed), you're welcome to email lwn@lwn.net.
Thanks for the corrections, and for your work on Zig!
Re: Zig's new plan for asynchronous programs
#180Overall this article is accurate and well-researched. Thanks to Daroc Alden for due diligence. Here are a couple of minor corrections: > When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away. While this is a legal implementation strategy, this is not what std.Io.Threaded does. By default, it will use a configurably sized th…
Daroc here — I've gone ahead and applied two corrections to the article based on this comment. If you want to be sure that feedback or corrections reach us in the future (and not, as in this case, because I'm reading HN when I should be getting ready for bed), you're welcome to email lwn@lwn.net. Thanks for the corrections, and for your work on Zig!
Noted, thank you!