Clojurians Log v2

Hi I'm trying to implement an advanced "pub/sub" for core.async. I have an incoming stream of data. I'd like to be able to subscribe to "queries". Basically, for each message that comes in, check which of the registered subscriptions matches. But I'd like it to be done efficiently, so if multiple subscriptions share a match condition, this would only be applied once to the incoming message. I have an almost working example here: https://gist.github.com/jjttjj/ad9c6355d8b6741b43f23e90c7c77442 But I'm wondering if I could use meander here, though I haven't fully wrapped my head around how that would look.

(sub pub
  {:venue ?venue
   :type (me/or :done :open)
   :price (me/pred #(< % 100000) ?price)}
  ch)

@noprompt @jimmy Could any of you explain why you need an iterator function in meander, here: https://ask.clojure.org/index.php/10303/interop-clojure-pattern-clojure-consider-adding-iter-clojure?show=10305#a10305 I'm trying to convince that clojure.core should expose an iter function like CLJS does.

Its used for memory variables. Two things: 1. I don’t like this 🙂 2. I think Clojure should expose iter as CLJS does. 🙂

After learning a bit more meander, I think a more direct question might just be, is it possible to m/search based from a map of pattern->clauses?

(def pattern->clause (atom {}))
(swap! pattern->clause assoc '[?x 1] :x)
(swap! pattern->clause assoc '{:a ?a} '?a)

(let [x (mapcat identity @pattern->id)]
  (eval `(me/search
           {:a 1}
           ~@x)))

Can you explain in the issue to Alex Miller instead of me? He is the one that needs this data

So I didn’t get to process all of this yet. For dynamic things we just started exposing an interpreter. But It is definitely not something we have focused on for performance. And it is no where near as battle tested as the non-interpreted version.

In fact, I just pushed up a fix for pred that someone discovered. If you are looking for efficiency as your primary attribute, I’m not sure it if is the right answer for you. But also, if you are looking for efficiency, you might want to think about how dynamic you want to be.

If @noprompt can’t find the time, I will try to explain. Though I will have to learn why myself 🙂. Any advice on the angle to explain it? I can’t imagine the core team will found the meander case very compelling. I’d imagine they would just suggest not doing it the way we do it.

Thanks! I'll look into the interpreter stuff a bit. And I still have a bit more thinking about my problem to do, and learning how meander works.

My angle is: not have to include clojure.lang.RT in babashka but still enable people to use meander in babashka

> I can’t imagine the core team will found the meander case very compelling. I’d imagine they would just suggest not doing it the way we do it. I agree and, on top of that, I don’t even want to be using iterator this way.

In meander this got fixed, but now I came across the same issue with pathom(3)

There is a larger problem though in that Clojure and ClojureScript have no core library “standard” of any kind between the two of them.

“Not very clojure-ry” is a really poor argument.

agreed

> They are stateful and generally not concurrency friendly. However, neither are arrays and yet make-array, etc.

The same argument was given for index-of: this will force a linear scan. Yes, so will filter ...

And I have wanted index-of myself (https://github.com/noprompt/meander/blob/epsilon/src/meander/match/epsilon.cljc#L246)

then please upvote and/or leave comment: https://ask.clojure.org/index.php/10295/consider-index-of-core-function-in-favor-of-interop-calls

> It’s not in core to promote better suited data types This is also a really shitty argument.

Maybe I should just release a babashka.utils lib that has all of this and you can also run it on the jvm ;)

It, in fact, doesn’t address the actual argument which is “I have a vector and I don’t want to call .indexOf; I would like cross platform support for this perfectly useful thing that exists that has these measurable performance characteristics.”

https://clojurians.slack.com/archives/C07UQ678E/p1615223936083600

Theres a history with CLJS being treated more as a dialect of CLJ rather than a CLJ for JS which has caused many of these problems. I think what has become clear over time is that host specific functions probably should be placed in their own namespace if there is ever going to be a day where core is platform agonistic.

I think the argument for iter is that it is practical when you need to do interop which requires an iterable instance, is probably one of the best.