On 2013-05-29, at 07:17 , Alex Crichton wrote:
>
>> In my opinion, rusti gets the job done. Yes, having in-memory compiled state
>> would work a lot better. But I don't know how viable that is. I know for a
>> fact that a big feature plan is to have the compiler only partially compile
>> when applicable, i.e. only compile things are actually important. That would
>> help drastically here.
>
> For me, if I use rusti I expect to get all of rust and everything that
> entails.
Although I don't think rusti works well enough now (I don't think many
would disagree), I think this expectation is essentially crazy, Rust
not being a language where everything happens at runtime, it seems
only logical that there will be limitations on what an interpreter
can do, just as there are limitations on what ghci[0] does compared to
ghc, or the erlang shell compared to an actual erlang module[1].
That said, I'd also expect additional features (not available in a
normal program) for observing and investigating the current available
environment as Rust doesn't (as far as I know) provide these in the
core language/library (for obvious reasons already mentioned):
where one can use standard ruby or python objects and methods to
introspect the interpreter's namespace[2], ghci has to provide a number
of dedicated command[5] to introspect the interpreter's state and
interact with the external environment sensibly.
[0] Talking about ghci, how does it work? Haskell is also a
"compile-heavy" language but ghci has very little issues, could
rusti work the same way?
[1] Part of these limitations stem from eshell being a console, a
shell, an interface for interacting with a running erlang node
before being a REPL. Which makes me wonder if Rust will provide
a basis for such things, providing arguments to the runtime
itself à la GHC[3] and allowing external tools to connect to
a running Rust program and inspect/interact with it à la
Erlang[4]?
[2] And even then, "augmented REPLs" such as ipython or bpython
have added REPL commands separate from Python's own.
[3]
http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/runtime-control.html#rts-opts-cmdline
[4] http://www.erlang.org/doc/apps/webtool/webtool_chapter.html
http://www.erlang.org/doc/apps/appmon/appmon_chapter.html
http://www.erlang.org/doc/apps/observer/observer_ug.html
http://www.metabrew.com/article/bigwig-erlang-webtool-spawnfest
[5] http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/ghci-commands.html
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
