Clojurians Log v2

The name alone is delightful!

@magnars and I were high-fiving a lot when we came up with that 😂

Yeah, spontaneously, it looks powerful. What makes me hesitate is that it’s likely going to result in a performance degradation. In contrast, I could likely use the latter to enhance performance. If given the collection predicate and key predicate separately, we can effectively cut branches off early. Let’s say we have some structure with a set of 1000 keywords and a vector of 1000 keywords. Let’s say we want to match all keywords in a vector when on even indices. Variant one: Predicate: (and (vector? data) (even? k) (keyword? v)) • ~2k vector? checks • 1k even? checks • 500 keyword? checks = ~3.5k predicate checks Variant two: {:coll-ped vector? :key-pred even? :val-pred keyword?} or something. • 2 vector? checks • 1k even? checks • 500 keyword? checks = ~1.5k predicate checks Everything in the algorithm has been otherwise trimmed to the point where running the predicate accounts for a significant portion of the total runtime. But something seems off with filtering on key and matching on key with :include-keys, I’m not sure about how to think of the interaction between them in either case. Makes me think I’ve complected something that shouldn’t be.

No, currently it only receives the value. A workaround would be to terminate the scan one step earlier: at the eg. vector level rather than the value level, and then perform the update there. There’s no way of expressing eg. “match keywords on even indices” right now. It might be the type of thing I would reach for Specter to express.

Yeah, specter comes to mind but I find it really difficult to remember how to use it when I reach for it every 12 months or so.

Technically the information could be made available, at least for transformation ops, where the key is kept anyway in order to construct the path to the value. But the predicate would get a rather odd signature: [data k v], but maybe that’s fine. Binding the data structure itself to data would be necessary, I think, in order to distinguish a case like k == 0, v == 0 if you’re in a set or a vector (since with sets, the key is logically the same as the value).

I figured you'd have it for that case, yeah. I'd even be happy with being able to look it up in the navigator separately.

Right, but I think the correct way to do it would be to disambiguate during scanning rather than during update. If you can exclude the false positives during scanning, the resulting navigation structure becomes smaller (fewer allocations), and during update, it doesn’t have to lift the structure just in order to do a no-op update.

How about you receive [data k v] , and you respond if the key was a match, the value was a match, or both were matches?

The other way would be to add more predicates to the options map: one predicate that filters the container / coll, and another that filters the key.

So in one world, you do something like

(path-when data
  (fn [data k v]
    (when (and (vector? data) (even? k) (keyword? v))
      VALUE-MATCH)))

In the other world:

(path-when data keyword?
  {:coll-pred vector?
   :key-pred  even?})

I think I prefer the first, it reminds me more of reduce-kv and I think it would be more flexible for considering both keys and values in your matching.

Pathling is a really neat library. I love seeing things like this for open data modification. I think there's a gap for something like this to step in and be a really simple way to do a lot of the kinds of things people need. In terms of the navigation structure, does the API include any information from there? Eg if I wanted to apply inc only to even-indexed items? Or under keys starting with "a"

@henrik By the way, there is a preexisting Clojure library called “quiescent”. It was one of the early ReactJS wrappers back in the day. It hasn't been updated in years, but it will come up first if you search “Clojure quiescent”: https://github.com/levand/quiescent

Ah, I should have checked. Wow, a decade ago now, and it looks like it was quite popular. Well, c’est la vie.

I can do the other thing though: put a notice for people looking for the React wrapper, should this ever be reranked on top.

It's also old enough to not be namespaced in Clojars: https://clojars.org/quiescent

Quiescent definitely had its day in the sun. I think it was the first React wrapper I used in anger.

Well, it shows you how harmful namespacing is. Without namespaces, I would have noticed when I tried to upload it.

I’m joking of course.

Ah yes. Convenient for access control policies, but not great for maintaining uniqueness.

Right. I really should have checked, but in this case I think the statute of limitations has probably elapsed for Quiescent (senior).

I think this is the beauty of namespaces, nobody can squat the good name

Agreed, namespaces are great in many contexts. Sometimes even the ones where you think you have complete control.

If you can win over the SEO, more power to you! I only mentioned it because I figured you'd rather know than be surprised further down the road.

Thank you! I have no need as such to promote it further than it will travel by itself (though of course it’s satisfying if I can help someone through it).

Also, I wonder how many people will just search for Quiescent and Clojure and go to the first result returned. “Oh well, guess I’m building a React app.”

It makes it hard to spread by name. It reminds me of the poorly named “schema” which came to be referred to as “plumatic schema”. To share it by name, you end up adding another word. Eg “quiescent vthreads” or something like that—at least until you top the SEO charts.

That’s true, although maybe mitigated by the alternative being a decade old. The truth is that the name and concept, and the behaviour I associate with it, is so settled into my mind now that I’d find it jarring to change. This has lived for a long time in a production codebase before now. The word “quiescent” came to be because I tried my best not to use “completed”, “ended” and other words with informal connotations, since the internal lifecycle effectively has several ends, depending on how you define “complete”.

I do love the name! Just to be clear, I'm not saying anything about needing to change the name or not.

Ah, right! Sorry, I guess I was projecting that.