That's a neat idea. But I'm curious how many people actually use native REPLs for anything beyond trivial evaluation.
I'll use a Guile or SBCL REPL for some quick math (assuming it's something that's not trivial in dc) or to test out a quick idea, but I rarely send more than one to three forms before closing it. That's only if I don't have Emacs open where I can just do it in the scratch buffer. Anything that needs more than a couple defuns goes into SLIME or guiser.
So, people who use native REPLs, what do you do with them?
You can look at it as heavily customized Scheme REPL, where everything not inside parentheses is parsed and executed as shell syntax,
and everything inside parentheses is parsed and executed as Scheme syntax.
Having arithmetic and procedure definition within the login shell definitely feels liberating, at least to me
I've used the Picolisp REPL like that, though not as a login shell proper, but as the shell where I actually do stuff. Mainly due to the ease with which it integrates with the below shell through 'in, 'out and 'fork.
The person you're answering is also using a REPL while coding, just not accessing it directly (= manually writing in the REPL stdin)
Instead he interacts with it via his editor's tooling, where you are in a normal file, and use a shortcut that will send a sexp/function/region/etc into the running repl and display the result.
So just to be clear you are using the repl directly?
The article mentions SBCL which is a well regarded open source Common Lisp implementation.
Common Lisp invented REPLs and the way most people use it now answers your question with "both".
A REPL usually runs locally in a subprocess or remotely through a REPL server and then your editor talks to that running Lisp Image where you can send code for compilation and recompilation while the image is running and also interact with it directly through the REPL which includes the debugger.
The GP you are referencing uses the common SLIME[0] package for anything of consequence which works exactly as described above.
So what's left is to answer GP question, which nobody has done:
What are the use cases for using the repl directly rather than through something like SLIME?
You answered "both" which I'm sure is correct, but I'm curious as to specifically which usages you find better directly through the repl. The only reason I can see is when you can't be bothered to (or are unable to) start SLIME, otherwise even to evaluate small expressions I'd rather have them written in a file to easily keep a history of them or edit them.
I also know people who never use tools like SLIME and prefer just using the repl for simplicity.
This was also my impression when reading the article, as someone who uses Sly heavily, every day. I can't imagine not having in-editor access to functionality like recompiling the function at point, or live evaluation of testing forms directly from the buffer. As Stew (the Clojure guy) pointed out in a video from a number of years ago, nobody should be typing anything raw into the in-editor REPL prompt; you should be sending forms directly from the code buffer.
How do I maintain that workflow if I'm to use native REPLs?
Loading programs, testing individual functions, examining data. I usually have two windows/consoles open: one for writing code, one for loading and testing.
That's a neat idea. But I'm curious how many people actually use native REPLs for anything beyond trivial evaluation.
I'll use a Guile or SBCL REPL for some quick math (assuming it's something that's not trivial in dc) or to test out a quick idea, but I rarely send more than one to three forms before closing it. That's only if I don't have Emacs open where I can just do it in the scratch buffer. Anything that needs more than a couple defuns goes into SLIME or guiser.
So, people who use native REPLs, what do you do with them?
> So, people who use native REPLs, what do you do with them?
In my case, I use my interactive shell https://github.com/cosmos72/schemesh every day as login shell.
You can look at it as heavily customized Scheme REPL, where everything not inside parentheses is parsed and executed as shell syntax, and everything inside parentheses is parsed and executed as Scheme syntax.
Having arithmetic and procedure definition within the login shell definitely feels liberating, at least to me
I've used the Picolisp REPL like that, though not as a login shell proper, but as the shell where I actually do stuff. Mainly due to the ease with which it integrates with the below shell through 'in, 'out and 'fork.
If I write lisp, a REPL is always running. Used for testing functions with input and debugging.
The person you're answering is also using a REPL while coding, just not accessing it directly (= manually writing in the REPL stdin)
Instead he interacts with it via his editor's tooling, where you are in a normal file, and use a shortcut that will send a sexp/function/region/etc into the running repl and display the result.
So just to be clear you are using the repl directly?
The article mentions SBCL which is a well regarded open source Common Lisp implementation.
Common Lisp invented REPLs and the way most people use it now answers your question with "both".
A REPL usually runs locally in a subprocess or remotely through a REPL server and then your editor talks to that running Lisp Image where you can send code for compilation and recompilation while the image is running and also interact with it directly through the REPL which includes the debugger.
The GP you are referencing uses the common SLIME[0] package for anything of consequence which works exactly as described above.
[0] https://slime.common-lisp.dev/
I think we're saying the same thing then.
So what's left is to answer GP question, which nobody has done: What are the use cases for using the repl directly rather than through something like SLIME?
You answered "both" which I'm sure is correct, but I'm curious as to specifically which usages you find better directly through the repl. The only reason I can see is when you can't be bothered to (or are unable to) start SLIME, otherwise even to evaluate small expressions I'd rather have them written in a file to easily keep a history of them or edit them.
I also know people who never use tools like SLIME and prefer just using the repl for simplicity.
This was also my impression when reading the article, as someone who uses Sly heavily, every day. I can't imagine not having in-editor access to functionality like recompiling the function at point, or live evaluation of testing forms directly from the buffer. As Stew (the Clojure guy) pointed out in a video from a number of years ago, nobody should be typing anything raw into the in-editor REPL prompt; you should be sending forms directly from the code buffer.
How do I maintain that workflow if I'm to use native REPLs?
I’ve used the Node REPL to check some asumption about some library. Also the python REPL in Emacs when I was writing some logic heavy script.
Loading programs, testing individual functions, examining data. I usually have two windows/consoles open: one for writing code, one for loading and testing.
What a lovely blog!