you can convert anything to a promise-like from promise, as long as you have some way to trigger the callbacks (for resolving or rejecting), so you could wrap a channel to make it do it. is this what you were asking about?

it would be great if there could be one spot that we could do the channel -> promise conversion so that we could have our resolvers just return channels if we wanted

and then we can appropriately handle promise rejections in one spot as well since traditionally core async channels don’t really have a notion of “rejecting”

Something similar to how sieppari works would be awesome where by default it only supports promesa but you can bring in another namespace to extend what async libraries are supported (https://github.com/metosin/sieppari#external-async-libraries)

This ^

I did some play here, and I checked its possible to also implement a promesa protocol to make other async things fulfill it, here is an example using core.async via said extension:

(extend-type cljs.core.async.impl.channels/ManyToManyChannel
  promesa.protocols/IPromiseFactory
  (-promise [this]
    (p/create
      (fn [resolve reject]
        (go
          (let [v (<! this)]
            (if (error? v)
              (reject v)
              (resolve v))))))))

(comment
  (let [start (system-time)]
    (-> (p.a.eql/process (pci/register
                           (pco/resolver 'foo {::pco/output [:foo-async]}
                             (fn [_ _] (go {:foo-async "the-value"}))))
          [:foo-async])

        (p/handle (fn [result error]
                    (println "RES" result error))))))

I probably wont provide this in the library to avoid having the dep on core.async at all, but it can be a separated library, or a documentation page with the snippet

what you think?

Good approach. I really like core.async myself but having completablefutures is a good default, especially on the jvm. And it's easy to plug one into the others (you can make completablefuture impl for core. async readport/writeport that follows promise-chan impl, then overhead is really low I guess)

I wouldn't bake in interceptor usage tho, this is more opinionated, there's no standard and there are multiple good impl. in clojure with subtle differences.

I think that’s a great solution! like you said it could be a separate library if there’s enough demand for it but it’s also a pretty small change that just mentioning it in the README should be enough