Besides s-exprs (which I'm not sure if they really matter; but definitely want to avoid for this thread), what feature doe the Clojure REPL have that the Scala/Groovy REPL lacks that allows Clojure REPL-driven-development to go more nicely than Scala/Groovy REPL-driven-development ?

Anyone here using https://github.com/gregsh/Clojure-Kit instead of Cursive? (Mainly interested in the open source nature + integration with IDE scripting console.)

I have the following:

(loop [keys* (keys result) db* db]
                     (if-not (first keys*)
                       db*
                       (recur
                         (rest keys*)
                         (assoc-in db* [:datasets (:id result) (first keys*)] ((first keys*) result)))))

null
Can't recur here at line 493 projectgun/events.cljs

How horrible is this if I want swap polymorphic on ref type?

(defn- swapper
  "Return swapper that executes f exactly once, preferably atomically"
  [ref]
  (condp instance? ref
    Atom (fn [f & args]
           (let [tried (atom false)]
             (swap! ref (fn [v]
                          (if (compare-and-set! tried false true)
                            (apply f v args)
                            v)))))
    Agent #(apply send ref %&)
    Ref (fn [f & args]
          (let [tried (atom false)]
            (dosync
              (alter ref (fn [v]
                           (if (compare-and-set! tried false true)
                             (apply f v args)
                             v))))))
    Var #(apply alter-var-root ref %&)))

🤢

the code isn't horrible, but the raison d'etre probably is

the Atom one looks suspicious to me. I can see how it would execute f once but the result is thrown away. Not sure what guarantees you want to make on f’s return value.

also ^

This looks a lot like the problem recently dealt with here: https://www.youtube.com/watch?v=IsS8ZCSUTUQ

I can't conceive of a situation where I need to "swap" on opaque targets

there’s also a subtle issue where you need to determine your semantics. Are you ensuring f is only called once per call site or f is called only once per value in the atom. If its the former, this is basically just a “deref, and reset!” with that explicit race value as you just keep clobbering. Otherwise it is very close to just a regular atom

Good points, thanks yall! I think in my case retries should throw. The reason is I'm making a UI for Reveal (live view) that watches any type of ref and has controls to update it

basically integrant/component/mount live view, where systems typically live in atoms or vars

I'm ensuring 1 call per call site since calls are side-effecting and non-retriable - starts and stops of the system

all terrible

use reset!, this sucks, pretending it is thread safe in anyway is a joke

it's, like, super useful for me at least

I might be reading it wrong but it reminds me of some Python code I had to debug a few years ago that extensively used properties where getters were mutating things.

this sounds pretty different...

but I think I'll use CAS at least for atoms

you have no reason to cas, and start/stop of systems in an atom via swap! explicitly violates the contract of swap

this is not threadsafe, and cannot be made threadsafe, to clutching to constructs like cas is silly

I'm not trying to make it threadsafe, I'm trying to make it recoverable

cas won't do that either

it will because the exception will contain started system that user will be able to stop manually

that is not a property of cas

I think it might be useful to have a little more context on the use case. • what's a story of the typical usage? • how many refs are usually involved? Always one, or varying numbers? • what's the story for usage when a "swap" fails?

Well yes, it is a property of swapper. I don't want to do just deref+reset because if a system was started by some other code between deref and reset I might have 2 systems running and both might need cleanup. Just doing a reset will leave prev system running, but it will be lost. CAS will keep that system running and will return extra system to the user so they can deal with it.

what you just described is wanting thread safety

"if a system was started by some other code between deref and reset"

the only way you are going to make a pile of mutable state and side effects thread safe is a big lock around it, which is basically what you are doing with your extra atoms

and once you have a lock around it, mutating it using clojure's reference model, why bother?

sticking systems inside mutable references is itself problematic

like an atom in an atom

that's how integrant/mount/component works, not much I can do about that

it is not

I cannot speak for integrant/mount specifically, but I use component a lot and can't recall ever putting the system in a ref, agent, or atom

you use it in a var probably

which is very nice, because alter-var-root is synchronised

usually there main function of the server starts the system and sets the var, the var is just there for repl reference and is never mutated

after that point

exactly, but mount uses atoms

and I hate mount and never use it, so this all tracks

I imagine people put component systems in atoms because the idea of mutating a var at system startup makes them squeamish, and "oh, if I am mutating something, it must go in an atom"

atoms are great. so is CAS. hating with no context is not

Have you considered getting tshirts made?

Hate is nether helpful. Be nice to each other ☮️

feels like a whole lot of hostility in this channel today

but maybe I'm reading into things

btw I don't hate mount, I use it at work now and it's more convenient than integrant (I have experience with both)

The component-like libs always seem to be the flame wars in Clojure haha. But in my experience, like all good flame wars, they're all a pretty good choice actually, and that's why it creates flame wars. Someone once said, when two senior engineer argue loudly, it means both their ideas are pretty damn good, so much so that they can't agree which one is better.

somewhat vaguely related note: when it comes to start/stop lifecycles, I find the most simple and easy approach to define it is to make a start function return stop function. then all imperative stuff can be in lexical scope of a single expr.

For example, reveal uses this start/stop pattern for its observable view. Defining a subscription behavior that watches taps, and then stops watching when the view is closed looks like this:

(defn- subscribe-tap [notify]
  (add-tap notify)
  #(remove-tap notify))