3 ms·

I will claim that the most important thing to understand about all three of the concepts in this article -- Fallibility, Asynchrony, and Iteration (as well as s

by saurik 4y ago

I will claim that the most important thing to understand about all three of the concepts in this article -- Fallibility, Asynchrony, and Iteration (as well as some that aren't discussed, but are to-me relevant, such as "Allocation: holds scoped resources" <- one I feel Rust and C++ reasonably-correctly assume every object / value might one day take part in) -- is that these are all monads (yes: including Iteration/List, which I think took me the longest to fully appreciate from the set of commonly-referenced monads); and, in a language with a more theoretically-sound core (aka, Haskell... and no: I am not a Haskell zealot by any means and in fact have wasted away most of my life for decades using C++ and Python), these "control-flow effects" (which is frankly a better name than "monad") are all supported using the same typeclass and rely on the same syntax, which not only ensures that every such "register" is correctly analogous with the others but even allows for end developers to extend the set of similar primitives without resorting to increasingly-fraught language modifications.

c54 4y ago
I think you’re making a good point that I probably agree with, but I can’t tell partially because your writing style is hard to follow. Your whole comment could be improved by separating into multiple sentences and moving the asides out of the main body of thought
- saurik 4y ago
  It could certainly be improved for reading at a glance... but, if you just pay attention to the punctuation, I kind of think inlining the "asides" there is better than simply trying to tree them out (which would be the fast way to fix it). Like: this is a comment, not an article... I am lying in bed (deeply wishing I were asleep) trying to quickly type a train of thought into my phone (a smaller one than I normally even use) and am even feeling forced to do so under a time pressure (as once a post gets enough comments you won't ever find anything). Often, I will even type such a comment at first and then--after posting it--take the next 20 minutes to "clean it up" into some paragraphs (but am not going to do that this time as I am hurting my elbow). You are welcome to just ignore my comment for today; and, maybe one day, I will have more than a few minutes to allocate to writing yet-another-article-on-monads that no one will want to read (and likely won't help anyone understand... see "the monad tutorial fallacy", one of my favorite articles / concepts ;P).
Rusky 4y ago
This is something that came up constantly while Rust was working on `async`, and the main reason Rust doesn't use this approach is that the usual low-level concerns around allocation/memory layout get in the way of just plopping a `Monad` trait in there. (There's a secondary reason which is that Rust does not have higher-kinded types and thus cannot even express `Monad` to begin with. It recently got GATs which can encode it, but that feature was designed as an intentional alternative to full complexity of higher-kinded types.) The author of TFA wrote this thread on the subject: https://twitter.com/withoutboats/status/1027702531361857536 https://twitter.com/withoutboats/status/1027702531361857536
- saurik 4y ago
  FWIW, most of the arguments in that thread are "you can't add monads to Rust", which seems like a perfectly fine thing to say and is quite likely true. I am not saying "you should add monads to Rust" and I certainly am not saying "it would be trivial to just drop a Monad trait in right now why aren't they doing that" ;P. I do believe, however, that there is a different design for a programming language that solves Rust's core needs (efficient and safe) and yet which supports something akin to generic "control-flow effects"... which, to be clear, might not fit the specific definition of Monad. Maybe, for example, such a language simply doesn't support early return (a feature I can do without). Maybe it has linear types (which I maintain are missing from Rust, and yes: I have read the article that claims it is difficult and will note that that same article also firmly admits it is possible). Maybe, instead of using Monad, the right interface for a control-flow effect is somehow designed around the concept of how optimizing compilers need to reify these effects into actual efficient code, or maybe the way to get them feels more like an unhygienic macro... the design space isn't limited here. To that end, the one bit of this thread that I personally find valuable is the argument that borrowing is somehow totally incompatible with the idea of a yield point that is a function, which I find both surprising but also possible... I certainly haven't put a ton of thought into it and am so tired right now I likely couldn't even appreciate a trivial and complete proof of such :(. Regardless: I also am not claiming that Rust shouldn't exist with its current trade offs (at least, for this reason... I do think its non-monadic design should have exceptions and am almost entirely sure they would be compatible with the rest of the language; I am extremely disappointed that they weren't provided). However, to see this article talking about these three things and only using the word "monad" a single time buried in some table near the end was quite shocking as it is trying to lay out a ton of unusual terminology for something the author clearly understands deeply... it almost feels like they are actively avoiding speaking the word "monad" ;P.
withoutboats3 4y ago
I also think monads are elegant, and you're write that effects can all be modeled with monads, but I think the notion of a monad abstraction is a poor fit for a systems language as I elaborated years ago in the twitter thread Rusky linked to.

by saurik 4y ago

c54 4y ago

I think you’re making a good point that I probably agree with, but I can’t tell partially because your writing style is hard to follow. Your whole comment could be improved by separating into multiple sentences and moving the asides out of the main body of thought

saurik 4y ago
It could certainly be improved for reading at a glance... but, if you just pay attention to the punctuation, I kind of think inlining the "asides" there is better than simply trying to tree them out (which would be the fast way to fix it). Like: this is a comment, not an article... I am lying in bed (deeply wishing I were asleep) trying to quickly type a train of thought into my phone (a smaller one than I normally even use) and am even feeling forced to do so under a time pressure (as once a post gets enough comments you won't ever find anything). Often, I will even type such a comment at first and then--after posting it--take the next 20 minutes to "clean it up" into some paragraphs (but am not going to do that this time as I am hurting my elbow). You are welcome to just ignore my comment for today; and, maybe one day, I will have more than a few minutes to allocate to writing yet-another-article-on-monads that no one will want to read (and likely won't help anyone understand... see "the monad tutorial fallacy", one of my favorite articles / concepts ;P).

Rusky 4y ago

This is something that came up constantly while Rust was working on `async`, and the main reason Rust doesn't use this approach is that the usual low-level concerns around allocation/memory layout get in the way of just plopping a `Monad` trait in there. (There's a secondary reason which is that Rust does not have higher-kinded types and thus cannot even express `Monad` to begin with. It recently got GATs which can encode it, but that feature was designed as an intentional alternative to full complexity of higher-kinded types.) The author of TFA wrote this thread on the subject: https://twitter.com/withoutboats/status/1027702531361857536 https://twitter.com/withoutboats/status/1027702531361857536

saurik 4y ago
FWIW, most of the arguments in that thread are "you can't add monads to Rust", which seems like a perfectly fine thing to say and is quite likely true. I am not saying "you should add monads to Rust" and I certainly am not saying "it would be trivial to just drop a Monad trait in right now why aren't they doing that" ;P. I do believe, however, that there is a different design for a programming language that solves Rust's core needs (efficient and safe) and yet which supports something akin to generic "control-flow effects"... which, to be clear, might not fit the specific definition of Monad. Maybe, for example, such a language simply doesn't support early return (a feature I can do without). Maybe it has linear types (which I maintain are missing from Rust, and yes: I have read the article that claims it is difficult and will note that that same article also firmly admits it is possible). Maybe, instead of using Monad, the right interface for a control-flow effect is somehow designed around the concept of how optimizing compilers need to reify these effects into actual efficient code, or maybe the way to get them feels more like an unhygienic macro... the design space isn't limited here. To that end, the one bit of this thread that I personally find valuable is the argument that borrowing is somehow totally incompatible with the idea of a yield point that is a function, which I find both surprising but also possible... I certainly haven't put a ton of thought into it and am so tired right now I likely couldn't even appreciate a trivial and complete proof of such :(. Regardless: I also am not claiming that Rust shouldn't exist with its current trade offs (at least, for this reason... I do think its non-monadic design should have exceptions and am almost entirely sure they would be compatible with the rest of the language; I am extremely disappointed that they weren't provided). However, to see this article talking about these three things and only using the word "monad" a single time buried in some table near the end was quite shocking as it is trying to lay out a ton of unusual terminology for something the author clearly understands deeply... it almost feels like they are actively avoiding speaking the word "monad" ;P.

withoutboats3 4y ago

I also think monads are elegant, and you're write that effects can all be modeled with monads, but I think the notion of a monad abstraction is a poor fit for a systems language as I elaborated years ago in the twitter thread Rusky linked to.