Fork me on GitHub
#cljs-dev
<
2021-10-22
>
emccue14:10:01

personally, with promesa existing i don’t see that much utility in direct async/await (async generators are a weird one though)

1
emccue14:10:59

(p/let [a async-thing] …) is just as good as (let [a (await async-thing)] …) would be

borkdude15:10:44

yeah, and the p/let macro is something you could write with about 10 lines yourself:

(defmacro plet
  [bindings & body]
  (let [binding-pairs (reverse (partition 2 bindings))
        body (cons 'do body)]
    (reduce (fn [body [sym expr]]
              (let [expr (list '.resolve 'js/Promise expr)]
                (list '.then expr (list 'clojure.core/fn (vector sym)
                                        body))))
            body
            binding-pairs)))

borkdude15:10:51

take that JS!

emccue15:10:07

Also a not insignificant fraction of cljs devs are on reframe, which has it's own async issues but is definitely outside the realm of async/await in domain code

dnolen16:10:00

but in the end the expression semantics is enough to just throw the idea out the window - and never consider again

dnolen16:10:17

in JavaScript you cannot return a value anywhere - in Clojure you can

dnolen16:10:29

these IIFEs are necessary

dnolen16:10:18

but JS async like core.async go is shallow

dnolen16:10:43

but it's shallow at the wrong level, the level of the target source

dnolen16:10:36

I suppose if you converted the CLJS to SSA form only in the presence of JS async this could work - but already the scope of this is far beyond

dnolen16:10:39

"just add these cool keywords!"

lilactown17:10:31

yeah i think the thing that would significantly change the calculus is https://github.com/tc39/proposal-do-expressions/

lilactown17:10:09

but again, it's just a proposal and it seems pretty huge and subject to change if it ever does make it in

dnolen17:10:52

right still would need to be accepted - and more importantly Closure would need to implement it