Minh Do and I are looking into how to improve rusti -the- repl, so that is
fast, efficient, and stable.  Minh is undertaking this as a final year
project in his CS undergraduate program, and I am mentoring that project
and plan to work on it my spare time.  We had a first conference call this
week.

I've spoken with Alex Crichton and started a few conversations on IRC #rust
to discuss how rusti might ideally work.  I'm posting to rust-dev to
solicit additional feedback, guidance, and input.

Goals (and an important non-goal) for an improved rusti experience:

As an application developer in rust, I want to evaluate the effect of a
small Rust statement or expression, so that I can quickly learn the impact
of that statement and immediately verify or correct its syntax based on
instant feedback.

As a developer, I want to be able to change one variable or function
definition without a full recompile, so that I can quickly and immediately
see the result of, and evaluate the impact of, the change.  [I'm impatient!
I don't want to wait for a full recompile of everything.]

As a person new to Rust, I want be able to try out the syntax and
expressions interactively, so that I can get a quick feel for the language.

Non-goal: comprehensiveness. While naturally we would like rusti to be as
close to rustc semantics as possible, strict conformance is not a goal for
this project.  That is, we don't feel it important that rusti has to cover
absolutely every data type, nor every corner of the runtime of this quickly
evolving language.

Since this last point may be of interest, I will give here a brief
background discussion of this comprehensiveness non-goal.

The interpreters available for other languages (ghci, erl, cling, lush,
gambit-scheme come to mind) are similarly constrained to not be exact
replicas of the compiled semantics of the language.  Experience from these
other languages suggest that there is still great utility is be gained from
having a stable interpreter even for a subset of the compiled semantics.

The important example that is present in my mind, from discussions on the
#rust channel, is that it appears that tasks/coroutines may be difficult or
needlessly complex for a repl (if written in rust itself, which lacks
exceptions) to handle. In other words, it may be very arduous (given
current encodable/decodable constraints) to implement in a rusti repl that
supports task and fail! semantics. While we are open to clever suggestions
about how to make that happen if it is indeed possible, this may still be
undesirable and out-of-scope for a resource-constrained project. The
classic tradeoff of 80% of the benefit for 20% of the effort should be
observed.

In short, we feel there is great value to be had in providing an
interactive prompt for discovering many portions of the language, even if
the user has to move to the rustc compiler to deploy the full power of Rust.


We welcome your input and involvement on all aspects of rusti - the - repl
improvement.

Kind regards,

Jason

--
Jason E. Aten, Ph.D.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to