This really belongs in #C053AK3F9 but since you've already asked it here: • In that block, you don't have just a map - you have a map wrapped in a set • Keywords can't start with digits. Perhaps you're getting the data from some JSON with string keys an then keywordize those keys - you shouldn't do it in this case • The code that does what you want, assuming that data is a map and not a set with a map:

(map key (filter #(nil? (:value (val %))) data))

(into []
      (keep (fn [e]
              (when (nil? (:value (val e)))
                (key e))))
      data)

this also isn't valid EDN? looks like you added a few extra { manually?

I use core.async for coordinating stuff a lot. totally depends on how you design your overall code though whether thats useful or not. I have never used web audio. so not sure what exactly is needed

other than that you can just control when you .then and maybe Promise.race or so

Oh, race is the exact opposite of what I need. :D Yeah, can't really say it better than "run async stuff as if it's sync". Don't think it's possible in general, but here I control all promises and all call sites, so it should be. But bloody hard, every tiny change has a chance to blow things up.

So, every execution begets a series of other executions, which can potentially be of length 0. The executor queues up executions, runs them one by one, and each execution is replaced with its result. Something like that.

I'm not familiar with core async yet. But i've played a lot with the equivalent in Go. This sounds like a perfect example for channels to me. How I'd approach it, is draw a state machine on paper first, or with excalidraw and then map it conceptually to channel mechanisms.

from erlang I inherited thinking in messages

so you basically have an atom sitting with your state. all .then just trigger messages. sort of like agent in CLJ, or workers in general

so at any point you can look at your entire state and decide what to do next

little verbose at times but great for control

with core.async this looks a little like this https://github.com/thheller/shadow-cljs/blob/ce92e41ebea65c499fb2cba9b19179e9c430ab71/src/main/shadow/cljs/devtools/server/repl_impl.clj#L109

basically one alt!! that selects over which channels you want to react to

and the loop keeps the state

I'd avoid doing this for CLJS because of the go macro generating too much code

but you can achieve the same entirely without core.async and just an atom

also basically how select works in go

How would that enforce total ordering though? I'm very hesitant to model it as an explicit state machine because there are a lot of states, most of them being intermediate ones ("the nodes are stopped but we haven't received the stop event yet", "the playback is initiated but the worklet is not yet loaded", etc.). Not sure one piece of paper would be enough, heh. I think it'll be solved if instead of "work queue" I use "work deque". I just have to make sure I never use .then except for some special cases.

If I understand the problem correctly you'll need an internal queue. Right? Every message (say, user events) that your statemachine can't process right now gets put on the queue, while you await the messages from your process.

you control the ordering. you just check your current state, if a message arrives out of order you buffer it somewhere

But that would require me modeling an explicit state machine, no? Otherwise, how else can I figure out whether I can process a message right now or whether it has arrived out of order?

Yes I would do it this way for sure.

Maybe draw up a very minimal one and use setTimeout to kind of explore it.

To get a better feel for how it works. At least I always need to do stuff like this.

Oh, that last part will absolutely not work for me. :D Whenever I get a "good feel" that it works properly, the actual users, that use that functionality extensively and intensively, manage to find ways to break it - ways that I can't even imagine by looking at the code. :) I still have no idea how one particular error has happened, even taking all the arbitrary ordering into account.

depending on how complicated your "loop" is a simple :state :foo and then (case state :foo ... :bar ...) might be enough

I just tend to feed all events into a generic (swap! state-ref process-msg {:op :foo ...}) type of thing

you can abstract this into many different layers, all depends on how complicated you want to make or need it

in JS it is pretty straightforward since there is only one thread

so you never have the problem of two threads trying to swap! the state-ref and maybe causing CAS to retry

(so triggering side-effects inside the swap no longer is a problem basically)

That's also the reason why it maps perfectly to a state machine.

yeah, its all state machines basically

with varying degrees of actual defined "machines" 😛

my state machine models are typically just maps that describe the transitions. Then I dispatch to the right function that takes [from to]

maybe that works for you too

Have you taken a look at https://github.com/funcool/promesa? It's do and let macros can force order on nodejs. Check https://funcool.github.io/promesa/latest/promises.html.

> in JS it is pretty straightforward since there is only one thread Would you say it's still straightforward given that most computation trees look like this

a
   / \
  b   c
 / \   \
d   e   f
   / \
  g   h

But maybe I'm thinking about it wrong and some things that I consider to be separate states should actually be lumped together or not be considered states at all.

don't model it as a tree 😛

I didn't mean it as what I'm modeling it as - it's just how calls happen.

there is absolutely no logic in any .then call. they all just feed into the same place

Yeah, but they don't ensure order.

your code ensures order.

this is really tough to talk about abstractly

Last time I did something similar-ish in JS I just triggered enriched events in the callbacks. with dispatchEvent . The events are custom events and the target is custom too (not an actual dom node). (As you might know, you can put stuff into a custom event via the details property.) This way you have one handler that then further dispatches the individual event messages: There is your state machine and your queue for messages that the state machine doesn't handle at that moment. I personally never required to use a queue like the one you probably need. But I use this type of pattern in UI programming quite often (while discarding messages that don't get accepted). But here is how I would do try to do it: The queue gets emptied while your state machine is in the appropriate state say "Accepting Messages", so any message gets processed after the queue is empty. The transition goes back to the same state "Accepting Messages" after each message it takes. (At least logically. While you empty the queue you might just do that without going through the state machine.) When a message comes in that require specific further processing while ignoring others, you transition into "Step One", which only accepts messages that puts it into "Step Two" and so on. While your state machine is in one of those steps, your handler will just put any other message into the queue, until the "Final Step" is reached and you got back into "Accepting Messages". I mention this because this kind of pattern has helped me a lot in order to coordinate asynchronous UI stuff. But it's also a matter of whether it really fits to your problem and whether you vibe with that mental model.

After writing a lot, thinking a lot, and cursing a lot, I realized that my main culprit is the fact that the composable API is both internal and external. Ended up extracting the external API into its own functions and making it serial via a common constantly reassignable promise. So far, seems to work alright.

If it helps, you can reduce calling of .then over a seq of transforms. Something like this (untested)

(defn serial-then 
  ([fs] (serial-then (Promise.resolve nil)))
  ([fs p] (reduce (fn [p f] (.then p f) p fs))))

Hmm, might need a do-seq or something, too. Haven't yet tried this technique with laziness.

@U90R0EPHA this doesn't work. .then runs in the next microtask and itself just returns a new promise

👍 for promesa flattening out complex async promise code. > So in other words, I need to run compositions of async operations as if they were sync. This sounds a lot like something promesa will help with.

I don't follow what your concern is @U05224H0W. This builds up a chain of .then calls. When the first promise resolves, its result is passed into f of the next .then, which itself must resolve before passing its result to the 3rd, etc.

> When the first promise resolves

so, yes the .then calls will resolve in order but that is not what this discussion was about. the example chained .then calls also do that, f().then(g).then(h)

you just made a function to write (serialize-then [g h] (f))

.then always runs in a micro task, it never returns a sync result. even if the promise is already resolved

I guess I didn't really catch what the complaint was. I just saw that he wanted serial processing, and was throwing that out as an easy way to get that. Not clear what "as if it's sync" should even mean, so I don't know what about the issue makes running in a microtask problematic. But I see now the complaint about duplicate f.then... calls conflicting, which is certainly not going to benefit from my suggestion.

Shouldn't matter for js/* stuff. I usually do (set! js/document -title "something").

I guess there is a detail to note: > Dots inside symbols ... are not detected by :infer-externs So we're safe in the case of js/document but not necessarily other namespaces

in shadow-cljs it should work for all js/* things