This is cool, compare

(defn absolver [s f]
  (fn [t] (try (s (t)) (catch Throwable e (f e)))))

(define (disj g1 g2) (lambda (s/c) (mplus (g1 s/c) (g2 s/c))))

Where mplus is

(define (mplus $1 $2)
  (cond
    ((null? $1) $2)
    ((procedure? $1) (lambda () (mplus $2 ($1))))
    (else (cons (car $1) (mplus (cdr $1) $2)))))

The final case is a stream, the second case is a thunk

I'll have to re-read that paper

It's fun to read, concise and yet builds everything up gradually without heading off into the deep theory which underlies the correctness in the implementation

Just like https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L634 It doesn't have to be a function , it could be defined by a channel

Then a channel is reducible but doesn't block, returns a go block

I don't see anything about the semantics of reduce which require it to be blocking in the calling thread

when I use clojure.core/reduce , I expect to get a value, not a lifted value

clojure.core.async/reduce is lifted many -> lifted one, like m/reduce

I know, I'm wondering if that's correct

Why shouldn't reduce preserve context?

so what you're suggesting is if you pass a flow to clojure.core/reduce , it does what m/reduce does and returns a task ?

yes

ok I understand

my rationale is as follows - we can say map is a private case of reduce? But map is defined for every functor and its definition is that it keeps context

Why shouldn't that context preservation be expanded?

map is not fmap

That's a historical mistake

in Haskell's implementation

in clojure too

Yes, but because Clojure is dynamic it was easy to add a transducer arity and call it a day

I remember I searched some time ago for a definition of reduce in terms which don't require lists, didn't find anything satisfactory

The "convenient" reason to do this is it reduces the surface area of missionary