I think he means like, how do you know the thing that will later read the value of x will do the read after all async operations have added their result to it?

Using mutation is always "preferred to be avoided", but atoms are also there for a reason, so it's kind of up to you to decide if this is some ugly hack in the context of what you are doing, or a necessary way that ends up making things simpler

Ah yes I see what you mean about receiving all values and knowing when it's done. In that case creating chans and pulling from them in an async/map would be better.

What is making your function async though?

I'm just thinking, agent kind of do what you're expecting and allow you to wait on them being done processing. But they also implement asynchronous behavior, so if the function is already async by other means it won't work

Otherwise in your case, you could use promise, like pass a callback that delivers the promise.

i think the use case where i ran into this wasn't actually async. it was a javascript function which returned intermediate values via a callback.

(for [y some-collection]
  (let [p (promise)]
    (some-async-fn-with-clbk y #(deliver p %)))

Oh you're talking ClojureScript?

ah yes sorry

but i guess the question applies in Java too

finding the original use case

https://ondras.github.io/rot.js/manual/#map

var map = new ROT.Map.Arena(3, 3);
var userCallback = function(x, y, value) {
    // do something with x, y, value e.g. store them
}
map.create(userCallback);

In ClojureScript I'd say core.async is the way to go

But what you do is fine as well, if you don't care to know that everything is done conjing before you read

i guess the reason i got confused is because map.create() is not actually asynchronous. it blocks until all the values have been called with userCallback.

so it seems strange to set up chans and use core.async

Oh, hum, if it blocks I think what you did is fine

yeah that temporary atom is what my friend suggested and i didn't like it but i think you and he are right that it's actually a good use of atom here.

Cause basically that API wants you to use it in an imperative way. Since it doesn't return results, but instead provides them to your callback

That's my 2 cent

thanks

I'd use a nested doseq with a (println) after the inner one.

Actually, you can just (apply println v) in doseq.

prn, if you want to preserve double quotes.

Thank you. I wasn't sure how. Ill give that a shot.

A relevant SO question: https://stackoverflow.com/questions/15580807/sharing-functions-between-namespaces-in-clojure Check out the email thread linked in the accepted answer.

This one: https://groups.google.com/g/clojure/c/NX_H16r4JY8/m/6qantiC_8iIJ

There's also quite a few relevant discussions if you search for "potemkin": https://groups.google.com/g/clojure/search?q=potemkin

nice, this is great

good grist for the mind

@U017QJZ9M7W have you seen how neanderthal does protocol based dispatching for different types per op? https://github.com/uncomplicate/neanderthal/blob/master/src/clojure/uncomplicate/neanderthal/internal/api.clj

This is actually in response to your "are multi-methods fast" question.

interesting, I have not

@U0CJ19XAM I don't quite see here how resolution is handled for different types...

https://github.com/littleredcomputer/sicmutils/blob/master/src/sicmutils/numbers.cljc#L155

vs this, say

https://github.com/uncomplicate/neanderthal/blob/81e943f86875ec595bdde9c3053de264c6606235/src/clojure/uncomplicate/neanderthal/core.clj#L155 That ^^^ is used across different data types as well as engines. It may be more involved than what you're looking for but it's stupid fast. I'm sorry I can't speak more to the neanderthal approach right now, but I highly recommend studying what was done in this library and how it interacts with cpus / gpus X cuda / opencl / blas. it's an incredible testament to clojure.

yes, this is a fantastic recommendation

to the extent that I can I want to simply extend the ability to use Neanderthan's data types into the sicmutils system

(defn insert-after [coll idx item]
  (let [[begin after] (split-at idx coll)]
    (concat begin (cons item after))))

I think it nukes itself on large sequences

Purposely not using xform here or just a misplacement of parens? I ask because I’m curious if there’s something I’m not aware of re: xforms.

(mapcat f) returns a transducer.

Oh, gotcha.

You were asking why @U3E46Q1DG didn't use the xform version!

(I misread the parens)

user=> (defn insert-after [items after item]
  (into [] (mapcat #(cond-> [%] (= % after) (conj item))) items))
#'user/insert-after
user=> (insert-after (range 10) 3 :x)
[0 1 2 3 :x 4 5 6 7 8 9]
user=> 

Yes, exactly. I’m thinking the xform master might have something to teach!

I think a lot of us "old 'uns" are so used to the non-transducer versions of core functions that we instinctively dash off quick snippets of code that way...

Yeah prolly.

Actually it was meant to use a transducer but I rushed it right before dinner. 😀

And to be honest I don’t like creating a vector just to concatenate it immediatly after.

So maybe

(defn insert-after [items after item]
  (into [] (fn [rf] (fn ([acc] (rf acc)) ([acc x] (cond-> (rf acc x) (= x after) (rf item))))) items))

But then why bother, collapsing everything in a reduce is no longer:

(defn insert-after [items after item]
  (persistent! (reduce (fn [v x] (cond-> (conj! v x) (= x after) (conj! item))) (transient []) items)))

yeah anything xform or transducer goes over my head still, so i'm gonna pass on those versions