4 ms·
It's not really accurate to think of core.async as mutable state at all, because by default channels are only queues in the sense of implicit waiting go blocks
by coolsunglasses 13y ago
It's not really accurate to think of core.async as mutable state at all, because by default channels are only queues in the sense of implicit waiting go blocks forming a queue.
Unless you use a buffer implementation, channels have no "placeness", you're not mutating/adding to a queue by parking a go block.
I liked everything else.
- michaelochurch 13y agoYeah, a couple of other people pointed that out. core.async has state (when buffers are used, in particular) but state is not exactly the same thing as mutability. Producers and consumers don't have unconstrained access to channels, in the way that users of a mutable cell (a Clojure atom, a ref cell, or just a variable in many languages) can clobber it at will. Likewise (although I didn't get into this) state doesn't necessarily violate referential transparency. Memoization uses state as an optimization, but doesn't interfere with RT.
- coolsunglasses 13y ago>Likewise (although I didn't get into this) state doesn't necessarily violate referential transparency. Boy do Haskell users ride that one hard.