Fork me on GitHub
#missionary
<
2021-11-28
>
ribelo09:11:11

Is there any way to check if the value is ap or sp?

ribelo09:11:34

If I understand correctly, both are just functions, so there is no way to check this

leonoel09:11:54

there is not

ribelo09:11:02

for this reason, passing this as a value between functions is problematic : (

ribelo09:11:35

but it's still awesome 🙂

Dustin Getz13:11:19

why is it problematic

ribelo14:11:21

let me give you an example of what this might be useful for

ribelo14:11:52

say we have an event bus that accepts either functions that execute or ap that, when executed, return functions that are merged back to the bus

ribelo14:11:29

in funcool/potok an event can return a new event that goes to the end of the queue

ribelo14:11:41

it probably doesn't matter much, but ap/sp could be a separate type that implements IFn/invoke

ribelo15:11:06

currently, if a function could take a function, ap or sp, there is no way to know how to handle it

ribelo21:11:18

Is it possible to copy ap? I would like to share one stream for several reducers

ribelo21:11:36

I know I can work around this by creating a new ap based on the same input, but maybe there is a simpler way

ribelo21:11:52

which means I have to do a couple of reactors, great!

ribelo21:11:47

@U053XQP4S I think I found a bug

ribelo21:11:13

basically it only works with m/watch, which after thinking about it is even understandable, but the question is whether it should work that way

1
ribelo22:11:10

m/watch returns continuous flow, rest returns discrete flow

leonoel06:11:52

could you explain what you expect and why ?

ribelo08:11:27

I got around this by simply using an atom

ribelo08:11:52

but, I was thinking of something like share from RxJS

ribelo08:11:03

I wanted to create an event bus that I could subscribe and listen as many times as I needed

ribelo08:11:47

alternatively the equivalent of core.async would probably be mult& tap

leonoel08:11:31

but that's not what your example is doing

leonoel08:11:40

you ignore the result of stream!

ribelo08:11:49

when doing trial and error it often turns out that I do not know what I am doing

leonoel08:11:21

stream! has pretty much the same semantics has Rx's .share and handles backpressure like core.async mult / tap

ribelo08:11:01

That means I can use m/?< and m/?> on stream! and it's cool?

ribelo08:11:43

I'm not at pc right now so I can't check this right away

leonoel08:11:00

you can stream! an ap

leonoel08:11:58

and you can also pass it anywhere a flow is expected like ?< and ?>

ribelo08:11:38

I suspect I'm misunderstanding something, but if I give myself a moment, it will probably pop into my head in a moment

ribelo08:11:37

That's probably not what you had in mind, because it doesn't work either http://ix.io/3GrM

leonoel08:11:22

(def box (m/mbx))
(box 1)
(def c
  ((m/reactor
     (let [>f (m/stream! (m/ap (loop [] (m/amb> (m/? box) (recur)))))]
       (m/stream! (m/ap (println :r1 (m/?> >f))))
       (m/stream! (m/ap (println :r2 (m/?> >f))))))
   prn prn))
;; :r1 1
;; :r2 1
(box 2)
;; :r1 2
;; :r2 2

leonoel08:11:41

this is what I think you're trying to test

leonoel08:11:46

note how the first event is properly propagated to both listeners, even thought they were registered after, this is a classic FRP problem that Rx fails to solve

ribelo09:11:26

thanks! I'll look at it later but it will definitely helps ❤️

ribelo12:11:42

generalizing, most problems are solved by using one reactor and it is not a good idea to use many, for one flow