On 13-05-28 09:03 PM, Alex Crichton wrote: > Now this doesn't sound that bad in theory. Normally rusti is for quick > computations. There's not much of a history and nothing really takes a > long time. This quickly becomes a problem though for anything which > uses resources. Let's say that you call io::println. Do you really > want that statement executed every time you enter a line into rusti? > What if you opened a file or a network connection? In my opinion, > re-running code is unacceptable.
Yeah. Probably what it should do is save any item decl statments (by name, allowing you to redefine them), discard any plain expr statements, and note the local var decl statements. Then compile a wrapper that reloads, evaluates exprs, and sends-back all those local var decls via serialization. Might require prepending #[deriving(auto_serialize)] to any local struct definition, but otherwise I think it ought to work. > This actually glosses over the fact that rusti currently doesn't even > save all input. It only saves declarations and definitions right now. > I made a patch to save assignments as well, but that still doesn't > work in all situations. I don't believe that there's a good way to > "filter the code" such that you "only get what you want" (which is > what rusti currently attempts). Huh. Would the scheme I outline above not work? Every variable does have to be introduced at some point, which means we can enumerate them and ask to have them loaded from serial form and sent-back to the REPL on subprocess completion. > Basically what all that means is that rusti has to save the world's > state between your lines of input to be my version of a REPL. To the > best of my knowledge (which could very well be wrong), this is not > possible to do in Rust. "The world", no. Just the local variables. And we can probably reject any local decl that fails the "we can save this" test. I mean, it'll be a little delicate, and not a perfect emulation, but I think it can _mostly_ work. > If no one gets what they want when they run it, and I don't believe > that anyone can ever actually get what they want, I don't think that > there's a reason to keep it around as a tool that is built into rust. > I believe that the 'rust run' command is an excellent alternative. No, > it's not as fast as rusti, but it's correct and you know exactly > what's happening. I don't necessarily think that this warrants the > removal of the "-Z jit" flag either, but it makes me seriously > question whether it's worth maintaining that code. I agree that a 'rust run' command, or indeed exploiting our support for shebang comments[1], should be sufficient for most users. But I'm not convinced the repl serves no purpose, yet (though it's true, I don't use seem to ever use it; I also write surprisingly little rust code these days). People ask for it, and it doesn't really bend the language any to support it. It _is_ a code-maintenance cost, of course, so I'm also curious what others think in terms of the balance of costs/benefits. -Graydon [1] https://github.com/mozilla/rust/issues/1772 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
