Clojurians Log v2

I’ve implemented a replacement for Electric v2's e/def that seems to work reasonably well. It’s a macro that defines a bunch of things, and there’s a need to bind dynamic vars at the app’s top level. And those vars are only known about at run time.

Currently I have to touch the top-level namespace to get it to recompile every time I add a new one of these vars, because the binding thing only knows what vars to bind at compile time.

Actually, ignore this. I think it can’t work. The thing that contains the list of things to bind isn’t and probably can’t be an Electric value, so no.

Does dynamic bindings not exist in v3?

bindings works fine, but you need to mention the things to bind in your source code.

Ah, so you essentially want a dynamic set of vars in the binding vector?

Yes, exactly

Why not just bind a well-known var to a map with dynamic vars as keys?

Or an atom, if you want it to have mutable semantics.

I think because of grain size of updates

Reactive updates

If you let a get into a map then, sure, the get will rerun every time the map changes, but that’s very cheap. Whatever depends on the get will not rerun unless its return value changes.

Although this is from kind of a Big-O perspective, maybe there are subtleties to v3 here.

Hmmm, yes. I will give that a go. Thanks. (I now have the thing that contains the list of things to bind as an Electric value, so I can try this.)

i am very confused, please post code

a clojure map has a dynamic keyset, this implies looping over the present keyset since your code has no static knowledge of the keyset is that correct?

you'd use e/diff-by over the keyset in order to get downstream reactive updates. you'll pay the diff-by each time the keyset changes. I think we can assume the keyset is small enough to pay the O(n) diff-by, because if you were writing clojure you would similarly be using O(n) operators such as reduce over the map and not be too worried about it

the next level up would be to represent the keyset natively in e/amb (at least until we use e/amb and e/fn to implement an electric-native ReactiveMap datatype giving you the usual get/assoc APIs but reactive)

if you experience performance issues, it may not be the O(n) e/diff-by that is the problem, it may be something else, like accidental roundtrips or accidental transfer of the whole collection inside a loop, stuff like that

Thanks for all that. I need to have a think about all this. I won’t post code for now, but I might at some later point after I have thought more.

How does this not block the server thread? Is it running on virtual threads?

Nvm, offload

this one is for the datomic users 😉