Customizing Lisp REPLs | Hacker News Reader

Customizing Lisp REPLs

aartaka.me

76 pointsnemoniac19 comments

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?

Loading programs, testing individual functions, examining data. I usually have two windows/consoles open: one for writing code, one for loading and testing.

Do you do REPL customization and Readline wrapping like in the article, or are you satisfied with the basic REPL capabilities?

I think I'll give your workflow a try. I might learn something interesting from it. Worst case, I'll gain new appreciation for SLIME.

(I like your books, BTW.)

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.

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?

It's "both" because if I want to interact with the SBCL REPL in SLIME I swap to the buffer for it and type in whatever I want which includes reader macros and such mentioned in the article.

> 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.

From a few old post by Paul Graham, he used to run Hacker News in the REPL of Arc in the REPL of Racket. So it was posible to make tweaks on the moment, like changing the title to "Innocuous News" as a joke for a few hours. Also, he once changed the parent of one comment and created a cycle in the DAG and that cashed the site for a while. I can't find the article now.

Anyway, a few years ago dang changed the backend to SBCL that is more REPL friendly, so I guess this comment is showed using the REPL of Arc in the REPL of SBCL.

I think this is saying different things? The question is how much of the direct interaction is with the REPL, not if a REPL is available to use.

Interactive development, and scripting that isn't tied to UNIX CLI culture.

But maybe I am strange, because I got to experience Smalltalk transcript, Oberon REPL, AmigaDOS and REXX, was into XEmacs when there were no UNIX based IDEs to chose from, got to use VB REPL before Microsoft killed it on VB.NET, Alegro Common Lisp, Caml Light,...

And I guess that is why nowadays I am a big Powershell fan, even if it errs on the verbosity side.

It is like having the debugger always turned on, and being able to script the OS as well.

Sure, but do you use the native REPL for those things or do you go through SLIME or equivalent? That's what I'm curious about.

If am already on the REPL, why open a terminal window?

If I create an executable with SBCL's save-lisp-and-die then run that executable, it presents a repl. Not really a development scenario, but more of a "running application" scenario. But, even then, if the executable creates a swank server, I can connect to that from SLIME.

What a lovely blog!

Reply on news.ycombinator.com