there is not. Note that there's no way to do this in core you have to put extra requirements on the data in the map. The easiest way to see this is that it is trivial to come up with examples where you would lose information. if f un-namespaces the keys in a map,

(f {:a/foo 1 :b/foo 2})
-> {:foo ?}

of course you can easily do this yourself:

core=> (update-keys {:a/foo 1 :b/foo 2} (comp keyword name))
{:foo 2}

and of course, be aware if you have non-keywords in your map

core=> (update-keys {:a/foo 1 :b/foo 2 [:a :b] 2}
                    (comp keyword name))
Execution error (ClassCastException) at multiset.core/eval409 (REPL:30).
class clojure.lang.PersistentVector cannot be cast to class clojure.lang.Named (clojure.lang.PersistentVector and clojure.lang.Named are in unnamed module of loader 'app')

My question would be: why do you want to do this @UAEH11THP? A common use case is to create JSON but the common JSON libraries all either do this for you or have an option to do it. In general, I recommend sticking with qualified keys -- they're idiomatic.

trying to satisfy coworkers who keep complaining about qualified keys 🤷

lemma at 'em! I'll "satisfy" them! :rolling_on_the_floor_laughing:

Why are they complaining?

"omg it's so many letters to type"

meanwhile they're okay with typing ReverseAuthorityLookupService in ruby so ???

> "omg it's so many letters to type" I'll just say #:prefix{:a 1, :b 2} and ::alias/a, ::alias/b... typing problem solved 🙂

that and destructuring with ::ns/keys

public abstract class ImageTranscoder

okay thanks I will go look up proxy 🙂

Also worked out the vars, looks like you wrap it all in a let binding, found this example which is similar to what I want http://gettingclojure.wikidot.com/articles:extending-java-classes-using-proxy

Do you want to convert SVG to BufferedImage? This can be done this way: https://github.com/Clojure2D/clojure2d/blob/98afeca7ecfe590395ed6a8dad4cc3b651422fd2/src/clojure2d/core.clj#L1798

thanks for that tip, I may continue down my current path if only to get more familiar with interop, even if I come back to the above solution

How about the naive hack of just looking at a var and if set, terminating inside the thread?

(def flag (atom false))

  (def f
    (future
      (loop []
        (if (not @flag))
          (Thread/sleep 500)
          (println "hi")
          (recur)))))

  (deref f 10 :timeout)
  (reset! flag true)

I see

Actually I'll go to #C01ALH5JGRJ. I realized the more essential thing am wondering is if I can leak resources with deref a request

Lisps treat functions as first-class objects, meaning they have identity, meaning no matter where you define mynamespace/my-function, the compiler replaces the one incarnation of mynamespace/my-function.

Is there some way to use multiple namespaces at once?

better to evaluate the form in the editor and not in the repl.

that way you will have some parity between the code and the state of your program

A common pattern is using "Rich comments" to hold code to evaluate only during repl development. Then you can use the editor as the only input for repl evaluation.

(defn foo [bar] bar)

; A `comment` evals to nil, essentially being discarded
;  at runtime.
(comment
  ; But you can place your cursor on the internal form
  ;  and command the editor to evaluate it in the repl.
  (foo :baz)
  )

When I was beginning in Clojure, I had the same issue as OP. The trouble was that I had no one to look at and I started Clojure by myself. So I didn't quickly pick up the common idioms and tools. I think this is something that gets overlooked quite often. Things like evaluating code in editor instead of the repl that seem so obvious to me now - I did not even know about back then. I guess when people tout the virtues of the REPL they forget to mention that you really shouldn't actually directly use the REPL. Anyway, what @U90R0EPHA mentioned. Those comment blocks end up as documentation in the end also where you can come back to the same code file some time later and look at the comment block and get an idea of how the code is supposed to work. (The only gripe I have about comment blocks is that it gets invalidated as the code evolves - some of the stuff in there won't work as function signatures and impl change. But I haven't found this a huge issue yet)

To evaluate code at the REPL prompt in a terminal, then (in-ns 'another-namespace) can be used to switch to anther namespace. To use functions from other namespaces in the current namespace, the other namespace should be required, then specify the fully qualified name (directory-filename) of the function to call.. To make this very easy, Clojure editors will evaluate a function or other code within the namespace defined in the current file, so regularly switching and requiring namespaces is not required. This is an overview of the REPL driven workflow I use for Clojure (with some example videos) https://practical.li/clojure/repl-driven-development.html

Now that I think of it, this seems to call for a reducer of some kind.

I just need to collect all promises in a vector and then pull out the data in a reduce...

Just pseudocode:

(mapv 
  (fn [page-start page-end] 
    (deref 
      (future 
        (query page-start page-end)))) 
  (get-page-ranges))

Something like that ^ ?

I need to look up what deref and future does

Wow

Actually let me check this. Not sure if this blocks 😄

Please keep in mind I'm also a beginner

It probably does.

Hehe, it's not life or death code

Assuming you’re on Clojure 1.11, paginated queries beg for the iteration function. Here’s a good intro post about it: https://www.juxt.pro/blog/new-clojure-iteration

@UC1DTFY1G I think what's an issue here, though is that the predicate to mapv should be side effect free afaik. However, that's a good start because it would allow me to at least collect all the futures in one vector. I could then handle all of them in a doseq.

@UPJP9G4G1 or: (pmap (fn [i] (Thread/sleep 1000) (* 2 i)) (range 1 10))

Don't know if you are ok with n amount of parallel API calls

But otherwise looks fine to me

I need to go but I'll try it later. Thanks!