-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Implement a REPL #83
Conversation
This allows the REPL to now preserve context, such as previously declared variables which can be used in future eval steps. Currently is only supported for variables, support for other types to be included soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR! This looks good overall, I left a few comments to resolve.
RE: "Allow user to enter additional code if the statement is incomplete" I think following the example in the mlua
repository would work well here too: https://github.com/khvzak/mlua/blob/0e4476c2e3be679552b110add270b2fd0f8fd2a0/examples/repl.rs#L33-L40
An inquiry as a passer-by, would it be possible to have the REPL as a Lune application instead of it being implemented in Rust? It would make things easier by the looks of it, and it would be dogfooding Lune to itself. |
As per various standards, REPLs are the in-built into interpreters, for quick code execution. |
* makes use of `directories` instead of `home` * use `anyhow::Result` instead of more verbose `Result<_, anyhow::Error>` * removes redundant match statement * removes NO_COLOR logic, already handled by `console` library
A question: As per the mlua REPL example, they check whether the error is for an "incomplete input" as such. In the case of lune, a |
I added |
Awesome! Will implement. |
I've implemented the input continuation feature, lmk if any changes required regarding that. |
The only thing I see unsatisfactory at the moment is this direct exit. I'll see what I can do to remove its usage. |
Looks good to me!
I added some more review comments that you should be able to just click accept on, after this I think CI should also pass and we should be good to go |
Co-authored-by: Filip Tibell <[email protected]>
Co-authored-by: Filip Tibell <[email protected]>
Co-authored-by: Filip Tibell <[email protected]>
Co-authored-by: Filip Tibell <[email protected]>
Co-authored-by: Filip Tibell <[email protected]>
Gone ahead and accepted the changes, apologies for my stupidity at some times! 😅 |
Without "context", this isn't really that helpful. I fear the "adding context support later" will never end up being added and we'll be stuck with a pointless repl. You can already run lune code from the command line by doing |
Context preservation would be blocked right now either way since there is no way for the REPL to get/set the function environment of what it wants to run. I'm in the process of rewriting the Lune scheduler right now and when that's done I think we will be able to integrate the REPL a bit more and get context preservation working. If you want to still keep the issue open though feel free to reopen it or even make a new issue for context preservation |
As for now, you could use one-liners separated by semi-colors (even though that's not very convenient), and it will serve the same purposes. At the moment, the REPL is an MVP, similar to what is already available for Lua 5.4 REPL. |
As requested by users before, this PR includes a REPL functionality which is invoked when Lune is run with no positional arguments. The REPL currently supports
Preservation of code "context" (variables declared in previous steps)What needs to be implemented/fixed:
Context preservation for other declaratives (such as functions, or globals)Global variable detections for pretty printingCloses #38.