Open yannham opened 3 years ago
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.
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.
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.
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).
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.
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.
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: