On 12-04-16 04:07 PM, Stefan Plantikow wrote: > Some algorithms just yearn for being written in a recursive style.
Or state-machine style, yeah. IMO the use case for tail calls is more state machines than recursion. But both can be rewritten without. I think it's just a style issue; I don't actually know of any cases where a rewrite from tailcall style to non costs more than a constant factor of contortion. But I agree it's a nice style to support if it can be kept cheap. > In erlang there is an interesting use of tail calls related to atomic code > migration Yeah, but they are running in a late-bound VM with a fixed repertoire of latent types. Everything about that environment is different. In rust, if you change anything about your datatypes a hot code reload couldn't work (it'll fail to find the same symbols). And even if you keep the types exactly the same, your lazily-bound PLTs will break. And even if they don't, any pointers into the static data regions of your DSOs will break. And so on. I went to some unusual efforts to try to support hot code upgrading at first in rust (as much as "manually linking DSOs") but have long since given up on it. It doesn't match this space. Use subprocesses. > At one point I wrote a wiki page that discusses the idea of making "tail > callability" a part of the function type. It's possible. But I (personally) feel this particular strategy is more cost than it's worth for the style benefit. Would be better to push on the costs to see if we can get them to "tolerable", if we want to keep the feature (or limit to "just module-local and static" or something). -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
