Apologies, I forgot to cc the list. On Thu, May 03 2018, Gary Fredericks wrote:
You would also have race conditions on the meaning of *1, *2, *3, and *e.On Thu, May 3, 2018 at 5:43 AM, Carlo Zancanaro <carlozancan...@gmail.com>wrote:>But what happens when a user set!s a var? is it effective for >all future evals but not the concurrent ones?I believe so, but I can't check right now. If I'm wrong I'll correct myself when I can check.
It turns out I was half-wrong. When you start an evaluation then the bindings will be set to the state that they were in at the end of the most recent evaluation. This can get a bit confusing when there are lots of overlapping evaluations, but when you're using the system interactively (eg. with CIDER) then you have a lot of control over the evaluation sequence.
The meanings of *1, *2, *3, and *e follow the same rules as the above. I still find it a bit weird that evaluating a form with C-M-x (or other in-buffer evaluation commands) changes those variables, though. I would prefer it if those variables only got set by an evaluation from the REPL buffer (which CIDER ensures are sequential). That way I could eval stuff with C-M-x without affecting the state of my REPL history variables. But that's a separate issue in my mind.
Carlo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en--- You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
