4 ms·

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 conc

by 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.
- pjmlp 4y ago
  The language geeks would probably say that language would be Linear Haskell or similar. Joining the productivity of automatic memory management, with the performance tooling that linear types can provide. Hence why I follow with great interest such experiments.
- Rusky 4y ago
  Sure- I didn't read your comment that way, my point was primarily just that there is no clear path to such a language yet. It's an open question of whether it is possible and how to accomplish it, and TFA is already another very small step toward answering that question. (I suspect their reason for avoiding the word "monad" was that it is totally alien and obfuscatory to a significant part of the target audience, and it's relatively easy for those who are familiar to connect the dots themselves, as you clearly did.)
- zozbot234 4y ago
  Aren't effect types generally related to Lawvere theories, as opposed to monads? AIUI the two differ most promimently in the way they compose; composition of monads being very much ad hoc. I didn't read OP as relating to monads specifically.

by Rusky 4y ago

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.

pjmlp 4y ago
The language geeks would probably say that language would be Linear Haskell or similar. Joining the productivity of automatic memory management, with the performance tooling that linear types can provide. Hence why I follow with great interest such experiments.
Rusky 4y ago
Sure- I didn't read your comment that way, my point was primarily just that there is no clear path to such a language yet. It's an open question of whether it is possible and how to accomplish it, and TFA is already another very small step toward answering that question. (I suspect their reason for avoiding the word "monad" was that it is totally alien and obfuscatory to a significant part of the target audience, and it's relatively easy for those who are familiar to connect the dots themselves, as you clearly did.)
zozbot234 4y ago
Aren't effect types generally related to Lawvere theories, as opposed to monads? AIUI the two differ most promimently in the way they compose; composition of monads being very much ad hoc. I didn't read OP as relating to monads specifically.