implement a proper REPL

[thestinger]

It shouldn't re-compile and re-run the entire input so far with each new addition, and should be able to recover from a compilation error or failure. This should likely be implemented in a separate repository until it's solid and has a working test suite.

A good basis for the design would be the cling REPL for C++ built on top of libclang using LLVM's JIT compiler.

[adnelson]

not sure why this (seemingly) isn't in higher demand. I would love to have a REPL.

[rklaehn]

This would be very nice. When developing scala, I really enjoy trying out language features in the REPL. It does not have to be perfect.

[thestinger]

Posting comments on an issue saying you want it fixed isn't going to make it happen any faster. It just decreases the signal to noise ratio on the bug tracker.

@adnelson, @rklaehn: Rust's test mechanism makes it really easy to run snippets in the same context you'd have in real code. I actually prefer it to ghci and friends. HTH.

[catharsis]

Would it be a good idea to implement this using the existing lexer/parser? I've had a look at mod.rs in libsyntax/parse and it seems to me that it wouldn't be too hard to build something that reads tokens from stdin and emitting tokens as they arrive. Actually, looking at driver.rs (librustc/driver/driver.rs) it looks like this is sort of already possible at a higher level through compile_input, though perhaps that doesn't provide quite the flexibility you'd want in a REPL - not sure.

I'd love to play around with this some (provided I can find the time), but I'd really appreciate if some of the more experienced devs would chime in and warn me off if it's a terrible idea or if there are other plans on how this should be done. Any other hints or suggestions would of course also be highly appreciated.

[abonander]

Could we make use of lli to interpret/JIT LLVM bitcode?

[thestinger]

There's no point in shelling out to a command-line utility when it can be done with the same library functions lli is using. The LLVM JIT is trivial to use, and the only difference relative to AOT compilation is that it's outputting code in-memory and making it callable via linker hacks rather than making an object file. It's not what makes this hard.

[alexchandel]

+1 for ease of adoption. I've learned most languages with the help of an interpreter (python, C#, JS, Haskell all have good ones).

[willprice]

I too agree with alexchandel, is there any work being done on this?

[hastebrot]

I also like to see the missing bindings for LLVMs ExecutionEngine implemented in the rustc crate. It seems that ExecutionEngine is needed for a REPL.

[jauhien]

Yes, ExecutionEngine seems to be needed. Are there any plans to implement full LLVM bindings in rust?

[thestinger]

Implementing a REPL is a complex project, and exposing / using MCJIT is a trivial piece of that puzzle. There's no point of getting side tracked on that issue here.

[japaric]

This issue is a feature request, and needs an approved RFC to be implemented (*). It should be moved to the rust-lang/rfcs repo. (As per the issues policy)

cc @nick29581

(*) I think it makes sense to develop the REPL out of tree (it would still be able to link to librustc, libsyntax or whatever is needed), if it needs more rustc internals/llvm bindings exposed, those bits can be requested via RFCs. (Note that I've no experience writing REPLs/compilers (the closest thing I've worked with are syntax extensions!) so I could be speaking nosense)