REPL

[yannham]

Is your feature request related to a problem? Please describe. An important piece to help the adoption of a language is a Read-Eval-Print-Loop, or REPL. It should provide a quick, easy and interactive way to try out the language.

Describe the solution you'd like Add an repl subcommand to the main executable which starts a REPL. Ideally, the code should be abstracted away from the terminal, such that the REPL may be easily ported to different environment such as being embedded in a website by compiling to WASM, or being usable in Jupyter notebooks by implementing the Jupyter protocol.

Describe alternatives you've considered Stay with the current executable. It may be possible to emulate part of REPL functions using a suitable configuration of an editor or IDE, but this requires a prior setup and won't have the same interactivity and ease-of-use as a builtin REPL.

Additional context Here is a list of desirable features we established:

• [x] persistent history (be able to recover past commands)
• [x] history search (Ctrl-R or via fish-style instant completion)
• [x] Emacs/vim keybinding (Ctrl-A/E/P/N/… users expect this things because they are used to them from bash/zsh/fish)
• [x] paged output (when the output is bigger than the screen)
• [ ] minimal config
• [ ] syntax coloring

[aspiwack]

I feel I've said this elsewhere. But jupyter console is quite probably the fastest route to a full-featured repl console. There are some rust libraries to this effect, which would simplify deployment, but they don't seem nearly as mature.

[aspiwack]

Adding to my previous comment. There is support for writing Jupyter stuff in Rust: https://crates.io/crates/jupyter-client . Which makes it even more convenient.

[yannham]

I agree this seems to be the fastest route if we are to develop a Jupyter-compatible REPL anyway, and this will also probably give us the online embedded REPL. Although, in the medium term, it may be nice to have a light standalone terminal REPL, because requiring Python, a Jupyter server, jupyter-console, etc. for this sounds a bit heavyweight (see https://github.com/google/evcxr/issues/139 for a similar discussion for the Rust kernel Evcxr).

It seems jupyter-client is not for writing a kernel, but a client to send commands to a kernel. I couldn't find a dedicated lib, or extract a stand-alone subpart of a rust library to do that (apart from unshameful copy/paste). Looking at the Evcxr Rust kernel part that implements the Jupyter protocol, implementing the jupyter protocol by oneself doesn't seem insuperable, but it's still annoying.

[aspiwack]

It seems jupyter-client is not for writing a kernel, but a client to send commands to a kernel. I couldn't find a dedicated lib, or extract a stand-alone subpart of a rust library to do that (apart from unshameful copy/paste). Looking at the Evcxr Rust kernel part that implements the Jupyter protocol, implementing the jupyter protocol by oneself doesn't seem insuperable, but it's still annoying.

Indeed… ah well. Still the kernel codee in evcxr_jupyter doesn't look big, and can even be vendored for our needs if relevant.

I don't disagree that installing and running Jupyter is an overhead for users. But I posit that you would need at least10 times the work to get feature parity if we roll out our own implementation, unless I've missed the existence of helpful libraries which would get you most of the way there.

So my argument is that Jupyter console is the shortcut. Not if we want to have a Jupyter-compatible repl, but in every case.

Maybe (probably?) we will eventually want a more native solution, but I don't think now is the time. I'd just roll out a Jupyter kernel, and, probably, add a nickel repl command which calls the relevant programs (and explains what to do when they are not running).

[yannham]

I was going to settle on rustyline for the native terminal frontend, which features (see also the key bindings below) look quite complete with respect to the goals: completion, history with reverse search, hints, vi/emacs key binding, etc.

[aspiwack]

Indeed. There is no screenshot, but I imagine, from the description, that the interface will be pretty stripped down. You may have to work some for the syntax highlighting bit too. But why not after all, that's a fairly minimal way to a prototype indeed.

[edolstra]

Nickel is supposed to be lightweight and adding a dependency on Jupyter makes it pretty heavy-weight. I'm also a bit skeptical whether there is a lot of overlap between Jupyter users and the intended audience for Nickel.