joyride 2022-05-12

Is TCL unable to access native JS promises? in order to VSCode interop it must be able to communicate with JS

What is TCL?

I meant TCI, corrected below sorry

What is TCI?

I'm going mad

synonyms for "little" small, tiny, teeny

SCI can access native JS promises

I was just trying to understand the problem, as I had a very similar one in cljs and the simplest solution seemed to be to just thinly wrap JS promises

yes, this is already what happens with promesa which is exposed in #nbb and #joyride (both based in SCI)

e.g.:

(p/let [x (p/delay 1000 :hello)] x)
returns a promise that returns :hello after 1 second

got you, I don't understand the question then

well, JS has something like:

const x = await(...)

a top level def employing an async thing has to either block or return a promise/channel/callback, so one can already use promises, can one block?

blocking is not possible and await is also not possible in CLJS normally

the closest is (<p!) right, (def ting (<p! other thing)) or (def tong (promise-wrapper (async-fn))

but #nbb evaluates differently

well, (def ting (<!p ...)) still makes ting a promise, not the value "inside" the promise

exactly, so the question is: can we surface nbb's ability to block?

yes, that's is what sci.async is becoming

and then joyride can use that

so the macro is moving the async from top-level 'inside' the def to 'outside' the def, failing pseudocode like (defmacro my-def [form]) (if (first-thing-in-form-is-<!) (let [res (<! (rest of form))] (def name res)) (def name (form)))

sorry that's definitely wrong but do I get the gist? Could this be expressed as a macro in cljs?

it's an interesting approach, I just accepted that I was going to have to unwrap a lot of promises

tcl brings back memories. 😀

I apologize to anyone who had to read the first part of this thread for my brain

is my question re the macro 'correct'? like if one defined defp with roughly the control flow I described, it would be equivalent?

I might actually do that it's more comfortable than all this unwrapping

I guess one problem would be if you block before running def then references to that def that resolve before it completes will blow up, SCI's approach can work because it can 'block' global execution, in clojurescript one would need to either spin or use 'delay'?

the normal pattern would just be (<p!)?

one can 'hack' JS promises too by capturing their request, resolve functions so that they can be resolved later, so since this creates a chain of definitions, you can choose to either make those defs return channels or promises

I had to do something like this in my (cljs) electron app and just used native promises

sorry by resolved later I mean resolved from outside their scope if that makes sense, making them act more like clojure promises

Now playing 🎵

🎸 1