Is it expected that *1 always returns nil when evaluated via clover?

Compatibility with *1, *2, and *3 is not guaranteed on Clover or Chlorine, so it's not reliable to depend on then...

@mauricio.szabo Just out of curiosity (as an implementor of several REPLs in babashka), why is that?

Because for some implementations (ClojureScript with Lumo, Clojerl, etc) I have to issue 2 commands (one to set current ns, other for the command) to be able to evaluate things. On these implementations, I also have to wrap up things like [this-is-an-eval-result with-this-id and-this-is-result] so *2 is bound to nil, everytime, and *1 is bound to a meaningless result.

ok, so basically a CLJS difference. Makes sense

When you re-evaluate things, *1 becomes *2 on the because of the first call, and so on 😄

(I also have a CLJS repl here: https://babashka.org/xterm-sci/)

I believe UNREPL also does this, so it happens on CLJ too. Things become even worse on Joker REPL, because it does not support multi-threads so "autocomplete" code is sent to the same connection as the eval...

ok, thanks for explaining.

@borkdude buuuut.... if I'm going to be completely honest, I didn't even remember that *1, *2, etc exist 😄 But then, when someone questioned me the first time, I did try to see if I could somehow make it work

I had a case recently where someone wrapped their own unREPL like code around the (new) bb pREPL and they wanted to be able to (set! *e ...) themselves

Using Reveal means that I can see any previous tap>'d value in the scrolling REPL and run computations on them (using *v to refer to the value). It's a nice compromise. I don't know if that's something that could be added to Chlorine/Clover REPL? Right-click to get a code eval box (but I'm not sure Chlorine/Clover REPL actually has access to the underlying value for past evaluations?).

Probably. I'll check it while I'm looking at alternatives for unrepl