How to use the REPL effectively?

[MarcusE1W]

Hi.
I have read in many articles that people praise how you can develop a lisp program with a REPL.

I have read a few articles like this Clojure one but then I can't find many of the functions described for Clojure in the Janet REPL.

I use it a bit to build data types and see if the brackets are right and I load a program and test functions individually. But this is a good example. Every time something is broken I have to edit it in the editor, save it and then close the REPL, open it again to load the latest version, define all relevant parameter and then test the function again. I have the strong feeling that I am doing it not right. I found (doc) useful and eventually found (quit) to close it, but overall it feels there is probably more.

As there is no documentation for the Janet REPL that I have found so far, how do you use it?
What would be a good way to program Janet and to use the REPL for help ?

[CosmicToast]

You're thinking of editor integrations for the REPL rather than the REPL itself.
This is dependent on the editor.
For neovim, for example, you have access to Conjure which supports spork's netrepl natively.

[sogaiu]

I find it a bit ironic that the mentioned article recommends the approach it does as one of the Clojure maintainers has advocated an approach which seems to be quite against typing directly into a REPL [1].

---

I also don't tend to type expressions at the REPL when working on a particular project. My editor is set up in such a way that I can "send" expressions to the REPL from source code and report on evaluation results. This has at least two benefits:

• expressions that are sent are first recorded in a source file (because that's where I type them in) so they are available for reference later
• there is much less switching between one's source buffer / window and a buffer / window for a REPL

---

As for testing, one thing I do is to put expressions (and expected values) in a source file and evalutate them via editor commands to observe results. I also invoke the tests using jpm test periodically via a terminal as that tends to avoid problems related to "state" issues that might be brewing in the ongoing janet process one is talking to via a REPL (after repeated "sending" of expressions).

There are more than a few testing options for Janet -- see here for a slightly dated summary.

If you haven't chosen a method yet and are not particularly attached to a specific option, I recommend starting by looking at spork's test and @ianthehenry's judge.

I mention these two because:

• spork/test

  • is the one I've seen used the most widely
  • is simple and very easy to get started with

• judge

  • offers a significantly different (and IMHO very valuable) approach
  • has some coverage here in "Janet for Mortals"

I don't have anything against the other options (one of mine is included!), it's just that I think the aforementioned two are good starting points and it may be easier to get help with either of them.

---

Regarding "help via the REPL", although I do use doc sometimes via the REPL, I tend to more often use the Ctrl-G shortcut when my cursor is right after an identifier -- though note that this is often in the context of using janet via a terminal to check something out quickly and not necessarily in the context of working on a project.

Also, I have found the approach of trying to "do everything via the REPL or an editor" to be unnecessarily restrictive. I also look at the website docs (the core API page is particularly useful) as well as janetdocs. I'm working on some tools [2] for getting help and practice with Janet too -- which I also use from a terminal from time to time (though some parts of their functionality can be accessed via an editor as well).

---

[1] See this transcript if interested.

[2] For example, jref for general Janet callables and pdoc for Janet PEG info.

[ianthehenry]

Semi-related: I use Judge pretty much as a replacement for a REPL most of the time, and instead of sending expressions to a running process, I have keybindings to patch source easily. I tried to write up a description of this general idea last month, from more of a polyglot lens: https://ianthehenry.com/posts/my-kind-of-repl/

This is a pretty big departure from the traditional interactive lisp repl workflow, though.

[MarcusE1W]

Thanks for all the answers.
I have almost no experience with working with a REPL so I really just wanted to understand why you sometimes read that it is such a great help for development.

This gives me a lot to do to work through the mentioned resources :-)

[sogaiu]

In my understanding, whether it's via @ianthehenry's mostly-not-so-REPL approach or a more traditional lispy REPL-ish one, one key appeal is the tight feedback loop in the process of articulating / typing one's code (whether it's in a source file or to a REPL prompt) and seeing its effects.

Why does that matter?

An extreme comparison might be what was typical many years ago when code was expressed on punch cards. Presumably one had to make the holes in the punch cards, take them somewhere for processing, hand them off, wait for some time, come back later to pick up output, and then start interpreting the results.

In the above scenario, one has to express the whole program and have the entire thing executed before seeing any results whatsoever. This is far from an optimal situation for learning / exploration in my opinion (see stuff by Bret Victor for more on this sort of thing, e.g. like this).

With the traditional lispy REPL approach, one starts up a program and can add to it interactively, seeing results along the way in a manner that doesn't usually tax our patience and/or adversely impact our attention / concentration. The startup time of some programming language systems has not always been great for this [1] and thus pushes things a bit in this direction to avoid the waiting / overhead that could be involved in restarting a given program.

As I understand it, with janet, at least for many programs I've seen, restarting the whole program doesn't take so long so there is less need (at least for those situations) to be "talking via a REPL". Indeed, though I also verify things via "sending" expressions, I also invoke my tests with jpm test as that doesn't typically take so long.

I haven't tried out judge, but perhaps janet's startup time is part of the reason that approach is feasible?

To quote the linked article that discusses judge:

Instead of typing something into a prompt and hitting enter and seeing the output on stdout, you type something into a file and hit some editor keybinding and the result gets inserted into the file itself. Patched on disk, right next to the original expression, ready to be committed to source control.

...

Once you have your expression and your “REPL output” saved into the same file, you can repeat that “REPL session” in the future, and you can see if the output ever changes.

And then you use this technique to write all of your tests.

Incidentally, there is a fair bit of similarity to how I do things. I also write my tests and expressions in my source files (not directly into the REPL) and have editor keybindings that insert evaluation results into my source code. The inserted results are used as expected values when the relevant code gets treated as tests via jpm test. One difference is that the results are obtained via a REPL connection.

I don't have anything set up to automatically update my expected test values though. I can see how that could be handy after certain kinds of changes. (I think that kind of feature probably should be used with care -- to avoid saving expected values that one did not validate in an appropriate fashion seems like asking for trouble down the line -- still, better to have the option IMO.)

A drawback of using the REPL (whether one is typing into it directly or "sending" expressions to it) is the potential for "messed up state" [2], but one upside is slightly quicker evaluation results (though I wonder how often one would notice).

In any case, it's possible that the two approaches described above are somewhat removed from traditional REPL development ones, so may be there are some other folks who might have different takes on this topic :)

---

[1] Clojure start up time was intolerably slow for the purpose of working on command line programs for a fair bit of its history -- at least I found it to be so. Clojure's startup time is much improved in recent times and, happily, there is Babashka these days :)

[2] Also, there may be various (often unnoticeable) semantic "gaps" between REPL interaction VS straight execution of code (e.g. janet source.janet). I think for Janet and Clojure these things may be hard to notice but it's much more obvious in other typically non-Lispy languages that have REPLs. When the gaps are big and/or the infrastructure in the programming language is lacking (e.g. try to do redefinition in Python while the program is running), the interactive development "illusion" can sometimes not be good enough and thus I imagine the approach is not as likely to gain much acceptance.