Re:Idiomatic Monads in Rust
by eslaught on Thursday April 04, 2019 @04:12PM
(#19576600)
There are languages where TCO is defined as part of the language spec, specifically to give programmers permission to write this sort of code. Some Lisps (Scheme, I think) and Lua work this way. TCO is a relatively well-understood optimization that isn't prone to being brittle the way e.g. auto-parallelizers or auto-vectorizers can be. So it's less fragile than you'd think.
[ Parent
| on HN ]
TCO is a lot easier to do in a garbage-collected language. In particular, with Rust, having any live stack value that conforms to Drop will break the ability to do tail-calls.
You could have a trait similar to Copy that forces Drop to be a no-op, and require live values that don't conform to it to be moved into any `become`.
Or just skip the trait and require there to be nothing live on the stack that conforms to Drop after a `become`.
In fact, the main reason to have a keyword like `become` is to signal to the compiler to do this kind of analysis, because it's so easy to accidentally break the ability to do TCO when you can't lean on a GC to clean things up later.
Didn't know about Lua[1], thanks! Although I think I would prefer an explicit
syntax, like Tcl's “tailcall”[2], Perl's “goto &sub”[3], or “become”[4], with
the compiler checking that this is actually a tail-call.
[1]: https://www.lua.org/pil/6.3.html
[2]: https://wiki.tcl-lang.org/page/tailcall
[3]: https://perldoc.perl.org/functions/goto.html
[4]: Which was used in a C-family language I can't remember.
Re:Idiomatic Monads in Rust
by steveklabnik on Thursday April 04, 2019 @04:42PM
(#19576897)
("become" is reserved in Rust for this exact possible future, maybe that's what you're thinking of.)