Clojure Q&A - Recent questions and answers in Contrib libs

Default implementation of AsElements to treat numbers as numbers, not strings

Tue, 28 Apr 2026 16:10:26 +0000

I'm slowly converting some code from using xml/element to xml/sexp-as-element, and I've noticed a discrepancy. xml/element does (almost) no processing of the "content", inserting it directly (unless it's nil). xml/sexp-as-element calls (str) on the "content" if it's not seq of some kind (vector or ISeq) or a keyword. This means that (= (xml/element :foo {} 1) (xml/sexp-as-element [:foo 1])) is false.

There are probably other differences, but this one seems relatively big, as there's no way to use numbers in xml/sexp-as-element without calling extend-protocol yourself.

May I recommend/request adding this extension? It will make xml/sexp-as-element match xml/element for numbers, and make xml/sexp-as-element match hiccup in general.

(extend-protocol clojure.data.xml.protocols/AsElements
  java.lang.Number
  (as-elements [n] [n]))

Answered: Is the recent change to flow's futurize safe?

Wed, 18 Mar 2026 13:41:35 +0000

Created ASYNC-275.

Answered: tools.cli: capture unrecognized options as unparsed arguments

Fri, 06 Mar 2026 01:40:33 +0000

Logged as https://clojure.atlassian.net/browse/TCLI-107 with a proposed syntax:

:subcommand :explicit will have the same meaning as :in-order true does today
:subcommand :implicit will have the behavior the OP wants here, i.e., an unknown option is treated as if there were an implicit subcommand present

Deprecate :in-order true (in favor of :subcommand :explicit).

Answered: Could some calls to clojure.core/= be replaced by clojure.core/identical?

Wed, 25 Feb 2026 23:51:22 +0000

The 1.2.x versions of core.cache use delays inside the wrapped ns so the original aspect of this Q is moot, but we could probably still change all those = to identical? for :: style keywords in the library.

Answered: clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Wed, 25 Feb 2026 23:07:51 +0000

Version 1.2.263 solves both the cache stampede bug and the cached exceptions bug, and does so without locking. Thank you, Claude Opus 4.6.

Answered: clojure.java.doc.api/javadoc-data-fn does not include constructor info

Fri, 13 Feb 2026 18:33:40 +0000

That functionality is now present in the v0.1.4 release.

Answered: javadoc-data-fn does not find selected method for inherited methods

Fri, 13 Feb 2026 18:33:01 +0000

Great feedback.

We were indeed not looking for inherited methods. That functionality is now present in the v0.1.4 release.

Answered: Core Cache and Count

Thu, 29 Jan 2026 14:03:17 +0000

Seems reasonable.

Created https://clojure.atlassian.net/browse/CCACHE-67

I'm happy to help screen a patch if you're so inclined to provide one.

Answered: `flow/ping-proc` can be slow or fail to respond, even when process isn't busy

Wed, 28 Jan 2026 19:54:27 +0000

Thanks, we've been discussing ways to specify filters for proc state datafication.

Answered: clojure.java.doc.api/javadoc-data-fn does not include return types for methods

Fri, 23 Jan 2026 21:55:59 +0000

I just released v0.1.3 that now includes the :return-type in the response from jdoc-data

Answered: How to access non-jar artifacts (aar, zip) downloaded via tools.deps in build.clj?

Wed, 24 Dec 2025 18:03:56 +0000

In tools.build you can find these paths in the :libs key of the basis when you build it, so that would give you the path.

You can then use unzip in the tools.build api to help unzipping it. See https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-unzip

Answered: flow monitoring tool serves resources from unqualified path

Mon, 24 Nov 2025 19:27:37 +0000

Resource path has been updated in v0.1.3

Answered: How do I effectively use EDN with C/C++?

Thu, 20 Nov 2025 12:20:54 +0000

I just finished optimised C implementation of EDN parser.

https://github.com/DotFox/edn.c

It is fast and highly optimised via SIMD instructions. By default it is pedanticaly follow official edn specification but can be extended to be fully compatible with clojure.edn via build flags.

As a small cherry on top you can add experimental text blocks support:

{:raw-json-string """
                  {
                      "id": 0, 
                      "name": "Kirill", 
                      "github": "@DeLaGuardo"
                  }
                  """}
;; => {:raw-json-string 
       "{    \"id\": 0,\n    \"name\": \"Kirill\",\n    \"github\": \"@DeLaGuardo\"\n}"}

`pipeline-blocking` uses `thread` internally instead of `io-thread`

Wed, 29 Oct 2025 15:54:00 +0000

pipeline-blocking is explicitly meant for blocking operations (implying I/O). However, internally it uses thread rather than io-thread for processing: https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async.clj#L637-L640.

Since 1.9.829-alpha2 this has practical implications, as only io-thread will utilize virtual threads, when available.

Can this be fixed / changed?
If not, can an explicit pipeline-io (or similar) function be added to support this use case?

Thanks

Answered: Can doc and jdoc be refactored to a common protocol while it's still early?

Tue, 28 Oct 2025 13:02:03 +0000

This library (which has not been released yet, and is still a work in progress) is focused right now on the narrow goal of reading Javadoc directly in the REPL. It's packaged as a library as a first pass. There are a variety of ways it might (or might not) be incorporated into core in the future - that is a question for later as we get feedback on the idea.

Because this library has a big dependency footprint, it's not something we would want to include in core directly, however it could potentially be incorporated via external tool invocation, much as we incorporate tools.deps classpath construction under add-lib using an external tool invocation with its own classpath.

Whether it could be incorporated into doc itself is a very open question. To date, we have simply extended the functionality inside doc (with specs for example) without making it an open system, but doing so is one interesting option available when we look at incorporation in the future.

Choosing between core.async pipelines

Sun, 26 Oct 2025 22:19:12 +0000

It's no longer clear what kind of pipeline is suitable for what kind of task in core.async.

Previously, my understanding was that anything I/O-bound should go into pipeline-blocking, while CPU-bound tasks went into regular (i.e. :compute) pipeline. But a while back :compute pipelines were changed to use threads instead of go-blocks. And now, with the introduction of virtual threads, pipeline-async seems like the right choice for I/O-bound tasks.

It seems that workloads are being classified into one of three types: :compute, :io, and :mixed. Is :async meant to be the equivalent of :io, and :blocking the equivalent of :mixed? I don't think that's original semantics, but it seems to be the mapping now.

Answered: An undocumented breaking change in data.json

Fri, 24 Oct 2025 18:28:16 +0000

I've updated the changelog to note this.

JSONWriter is not something users usually extend themselves, although it is available for that level of customization when necessary. However, we did know this had the potential to break some users and updated the version from 1.x to 2.x due to that.

Allocation churn on generators

Tue, 07 Oct 2025 21:16:10 +0000

When generating moderately large values there is some LazySeq churn that could be avoided. For example, the following snippet allocates over 15GB (measured with async-profiler):

(core/let [g (vector (not-empty string-alphanumeric) 1000 5000)]
  (time
   (dotimes [seed 50]
     (dorun (generate g 100 seed)))))

The pattern of generating multiple (increasingly larger) values is common with quick-check (via deftest et al).

Many generators are built on top of choose, and there is an opportunity to reduce churn by special casing shrink-int for longs (which should be the common case compared to big ints).

I have a patch that decreases total allocations of the repro above by ~15% and speed up the run time by ~25% (measured on jdk 25, with -Xmx512m -XX:+UseSerialGC to decrease variance). Happy to share it.

Answered: Replace core.async’s internal LinkedList queue with ArrayDeque?

Wed, 03 Sep 2025 20:10:39 +0000

There is a ticket for this at https://clojure.atlassian.net/browse/ASYNC-231

Answered: Typos in Flow guide

Mon, 18 Aug 2025 13:35:12 +0000

Already fixed, thx

Answered: tools.build compile-clj capture out/err

Mon, 28 Jul 2025 20:00:23 +0000

Logged as https://clojure.atlassian.net/browse/TBUILD-46

Answered: Is core.async.flow available in ClojureScript?

Fri, 18 Jul 2025 19:10:40 +0000

No, we are not currently targeting it to ClojureScript as it's really intended for writing multi-threaded applications.

Answered: tools.build fails with http_proxy/https_proxy set

Wed, 02 Jul 2025 12:48:08 +0000

A quote from Alex Miller that was used at least once to explain why the support isn't there:

We’re going through the Maven apis for that stuff and that’s just not how it works
[...]
tools.deps supports that via the mirror/proxy settings in settings.xml

So your script could be creating settings.xml with the right content dictated by http_proxy.

`create-basis` silently accepts missing aliases

Tue, 10 Jun 2025 00:57:37 +0000

In this scenario, the alias for create-basis was incorrect, preventing security deps overrides from being applied. For 2 years clojars was deployed with these vulnerable deps.

In this case, I proposed to inline the alias into :deps. However there may be other scenarios where a tools.deps change might be helpful to catch these mistakes earlier, for example a warning or error.

Answered: Dependency between options in Clojure/tools.cli ?

Tue, 27 May 2025 15:28:13 +0000

There's nothing built-in. The simplest solution would probably be to post-process the result of calling parse-opts to check that if :a is present, so are both :f and :d.

I often wrap parse-opts in a post-processing step for "global validation" (that takes the result of parse-opts and produces an identical structure, with extra :errors entries).

Answered: what kind of systems could be made with clojure.async.flow?

Tue, 29 Apr 2025 16:19:18 +0000

core.async.flow is particularly well suited to what Rich called "situated programs" in the "Effective Programs" talk https://www.youtube.com/watch?v=2V1FtfBDsLU . These programs execute for long periods of time (often continuously), deal with information, have extensive "memory" (via database connections), and interact with the real world via external I/O channels (these days, often messaging systems like Kafka etc).

You're correct that flow is a poor fit to run in a lambda or in a an RPC style web request path - you are probably better served in writing synchronous code for those scenarios and avoiding the setup and async overhead. But those kinds of processes often feed one or more situated programs via a message queue or database insert.

I would also recommend Rich's "Language of the System" talk which predates flow and core.async(!) by many years but is very much of this idea. https://www.youtube.com/watch?v=ROor6_NGIWU

Answered: tools.cli: Support default value for arg with value

Mon, 28 Apr 2025 19:08:37 +0000

The closest you can get is this:

clojure.tools.cli=> (parse-opts ["--diff="] [[nil "--diff NAME" "Diff" :parse-fn #(or (not-empty %) "foo")]])
{:options {:diff "foo"}, :arguments [], :summary "      --diff NAME  Diff", :errors nil}
clojure.tools.cli=> (parse-opts ["--diff=bar"] [[nil "--diff NAME" "Diff" :parse-fn #(or (not-empty %) "foo")]])
{:options {:diff "bar"}, :arguments [], :summary "      --diff NAME  Diff", :errors nil}

clojure.tools.cli=>

As discussed on Slack, there are reasonable cases for a value-bearing option to want to accept a string that starts with -- or just - (consider = to be optional here):

meta-command --option-to-use=--cabbage... \
--divider=--sep-- \
--value=-1

Answered: clojure.tools.reader.edn/read can cause incorrect column number for token at end of input

Wed, 05 Mar 2025 18:50:00 +0000

Logged as https://clojure.atlassian.net/browse/TRDR-75, happy to see a patch.

core.async go block error with clojure 1.12 method values

Tue, 25 Feb 2025 19:17:23 +0000

I haven't seen this reported.

(Long/.toString 123) ;;works
(a/<!! (a/thread (Long/.toString 123))) ;;works
(a/go (Long/.toString 123)) ;;error

Note: The following stack trace applies to the reader or compiler, your code was not executed.

CompilerException Syntax error macroexpanding a/go at (1:1). {:clojure.error/phase :macro-syntax-check, :clojure.error/line 1, :clojure.error/column 1, :clojure.error/source "NO_SOURCE_PATH", :clojure.error/symbol a/go}
ExceptionInfo No matching method: .toString for class: class java.lang.Long and arity: 1 {:method .toString, :class java.lang.Long, :argc 1, :file "NO_SOURCE_PATH", :column 7, :line 1}
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:127)
	clojure.tools.analyzer.passes.jvm.validate/validate-call (validate.clj:87)
	clojure.tools.analyzer.passes.jvm.validate/eval4802/fn--4803 (validate.clj:137)
	clojure.lang.MultiFn.invoke (MultiFn.java:229)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:265)
	clojure.tools.analyzer.passes.jvm.validate/validate (validate.clj:240)
	clojure.lang.Var.invoke (Var.java:386)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3429 (passes.clj:167)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.tools.analyzer.passes/compile-passes/fn--3424/fn--3431 (passes.clj:169)
	clojure.core/partial/fn--5929 (core.clj:2648)

Answered: clojure.java.data/from-java throws stack overflow

Thu, 20 Feb 2025 00:06:57 +0000

Christos,

Can you provide more detail on exactly how I can reproduce this?

Preferably, a small completely self-contained repo on GitHub with a README explaining the steps.

Without more information, I cannot even begin to figure out what might be going on here.

Answered: Auto-descending in clojure.data.zip doesn't seem to make a difference

Wed, 19 Feb 2025 21:26:05 +0000

Logged as https://clojure.atlassian.net/browse/DZIP-10

Answered: Please consider making tools.build pom.properties reproducible (e.g. the "Generated by" date)

Sun, 16 Feb 2025 23:04:32 +0000

If you want to provide a patch, I'd be happy to merge it.

I've created an issue here: https://clojure.atlassian.net/browse/TBUILD-44

You've already signed the contributor agreement and I've sent you an invite to the jira system via that email.

Answered: clojure.java.data.builder fails with overloaded setter

Wed, 22 Jan 2025 23:35:40 +0000

Since modelName is not supplied as a property, in this case it could just ignore that setter altogether -- so I consider that one bug (java.data will fail if there are overloaded setters that you don't care about).

In the case where you are trying to build with a property that is overloaded, java.data would have to perform some sort of overload resolution to try to pick a "best match" which would be fairly complex.

What it could do is pick one setter for which instance? is true of the parameter type and the property value -- and complain if more than one setter satisfies that. That would still be somewhat overprescriptive but it would be less restrictive than the status quo.

See https://clojure.atlassian.net/issues/JDATA-24 and https://clojure.atlassian.net/issues/JDATA-25

Answered: tools.namespace remove-node does not remove outgoing dependencies from :dependents

Mon, 20 Jan 2025 03:53:12 +0000

I don't actually know the original intent but the docstring you quote says "without removing it as a dependency of other nodes" which sounds like what it does?

unable to use add-lib on io.github.borkdude/grasp

Fri, 17 Jan 2025 14:15:15 +0000

repro:

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1

This seems strange to me. The deps edn of grasp: https://github.com/borkdude/grasp/blob/master/deps.edn

{:deps {org.babashka/sci {:mvn/version "0.3.2"}}
 :aliases {:native {:jvm-opts ["-Dclojure.compiler.direct-linking=true"]
                    :extra-deps {org.clojure/clojure {:mvn/version "1.10.2-alpha3"}
                                 org.clojure/tools.cli {:mvn/version "1.0.194"}}}
           :test {:extra-paths ["test"]
                  :extra-deps {org.clojure/clojure {:mvn/version "1.11.0-rc1"}
                               cognitect-labs/test-runner
                               {:git/url "https://github.com/cognitect-labs/test-runner"
                                :sha "cb96e80f6f3d3b307c59cbeb49bb0dcb3a2a780b"}}
                  :main-opts ["-m" "cognitect.test-runner"]}}}

It's surprising to me that deps in the :test alias would cause issues.

EDIT: seems to work now. Here's the stacktrace from a socket repl where i first encountered it

user=> (add-lib 'io.github.borkdude/grasp {:mvn/version "0.1.4"})
Execution error (ExceptionInfo) at clojure.tools.deps.interop/invoke-tool (interop.clj:81).
Could not find artifact org.clojure:clojure:jar:1.11.0-rc1
user=> nil
user=> (pst)
ExceptionInfo Could not find artifact org.clojure:clojure:jar:1.11.0-rc1 {:via [{:type clojure.lang.ExceptionInfo, :message "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}, :at [clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167]}], :trace [[clojure.tools.deps.extensions.maven$get_artifact invokeStatic "maven.clj" 167] [clojure.tools.deps.extensions.maven$get_artifact invoke "maven.clj" 155] [clojure.tools.deps.extensions.maven$eval1225$fn__1228 invoke "maven.clj" 178] [clojure.lang.MultiFn invoke "MultiFn.java" 244] [clojure.tools.deps$download_libs$fn__802$fn__803 invoke "deps.clj" 466] [clojure.lang.AFn applyToHelper "AFn.java" 152] [clojure.lang.AFn applyTo "AFn.java" 144] [clojure.core$apply invokeStatic "core.clj" 667] [clojure.core$with_bindings_STAR_ invokeStatic "core.clj" 1990] [clojure.core$with_bindings_STAR_ doInvoke "core.clj" 1990] [clojure.lang.RestFn invoke "RestFn.java" 428] [clojure.lang.AFn applyToHelper "AFn.java" 156] [clojure.lang.RestFn applyTo "RestFn.java" 135] [clojure.core$apply invokeStatic "core.clj" 671] [clojure.core$bound_fn_STAR_$fn__5837 doInvoke "core.clj" 2020] [clojure.lang.RestFn invoke "RestFn.java" 400] [clojure.lang.AFn call "AFn.java" 18] [java.util.concurrent.FutureTask run "FutureTask.java" 317] [java.util.concurrent.ThreadPoolExecutor runWorker "ThreadPoolExecutor.java" 1144] [java.util.concurrent.ThreadPoolExecutor$Worker run "ThreadPoolExecutor.java" 642] [java.lang.Thread run "Thread.java" 1583]], :cause "Could not find artifact org.clojure:clojure:jar:1.11.0-rc1", :data {:lib org.clojure/clojure, :coord {:mvn/version "1.11.0-rc1", :deps/manifest :mvn, :dependents [io.github.borkdude/grasp], :parents #{[io.github.borkdude/grasp]}}}}
	clojure.tools.deps.interop/invoke-tool (interop.clj:81)
	clojure.tools.deps.interop/invoke-tool (interop.clj:41)
	clojure.repl.deps/add-libs (deps.clj:48)
	clojure.repl.deps/add-lib (deps.clj:59)
	clojure.repl.deps/add-lib (deps.clj:59)
	user/eval310956 (NO_SOURCE_FILE:320)
	user/eval310956 (NO_SOURCE_FILE:320)
	clojure.lang.Compiler.eval (Compiler.java:7700)
	clojure.lang.Compiler.eval (Compiler.java:7655)
	clojure.core/eval (core.clj:3232)
	clojure.core/eval (core.clj:3228)
	user/eval257807/fn--257810 (NO_SOURCE_FILE:8)

Answered: Incorrect docstring for parse-opts

Tue, 03 Dec 2024 20:13:25 +0000

This relates to https://ask.clojure.org/index.php/14260/providing-nil-for-long-option-tools-cli-does-seem-work-readme and I plan to update the docstrings and readme to fix both.

Answered: Accidental breaking change in data.json 2.5.0: previously, read succeeded, now it isn't

Tue, 26 Nov 2024 19:44:16 +0000

A PBR with buffer size >= 64 must be supplied if you intend to do repeated reads on the same string. The docstring to read has been further updated in 2.5.1 to include this.

Answered: Providing nil for long option in tools.cli does not seem to work per readme

Tue, 19 Nov 2024 22:32:20 +0000

Try adding :required "MODE" after :id :mode.

When there's no long option in the form of --option ARG, the parameter is treated as a boolean flag, so you have to explicitly tell tools.cli that an argument is required by the parameter.

Answered: Multi-threaded cache stampede in core.cache

Sat, 09 Nov 2024 07:03:42 +0000

The 1.2.0-SNAPSHOT should address this. Please try it and confirm whether it does.

Answered: Is the clojure.cache behavior for lookup-or-miss value-fn re-entrancy broken or am I misunderstanding the docstring?

Sat, 09 Nov 2024 07:03:21 +0000

The 1.2.0-SNAPSHOT should address this. Please try it and confirm whether it does.

Answered: How can I ensure that a private Maven coordinate cannot be shadowed in a public repository?

Fri, 01 Nov 2024 18:03:32 +0000

The main current answer is that the public repos are trying to prevent this.

There are two public repos included in the root deps.edn - Maven Central and Clojars. All other repos must be explicitly included in the top-level deps.edn in use (transitive deps.edn repos are ignored - this differs from pom.xml).

Maven Central has policies to encourage using reverse domain names and/or trademarked names that you control, with requirements for verification. Clojars is now doing similar things, but their naming policies are somewhat laxer and I don't know the current state of everything they are doing.

The signing key stuff is problematic for lots of reasons (clojars doesn't require, keys must be registered - how do you know if the key you find is one you should trust, etc). This requires a lot of manual intervention. I have been following SLSA which I think is taking a smarter approach to provenance and verification. Would love to spend some time really working on how to integrate something like this into both our Clojure build systems and our dependency management tools to work together. Especially for open source libraries distributed as source, we should be able to hash+compare the actual source and relate it to a commit - Clojure's options are WAY BETTER than compile-to-class langs that make new artifacts different than the original source.

Hoping to spend some time on this kind of stuff next year.

Answered: clojure.data.xml.event: EndElementEvent should provide tag and location-info

Mon, 14 Oct 2024 13:36:17 +0000

I've added https://clojure.atlassian.net/browse/DXML-75 - if you could make that a little more detailed in addition to a patch, that would be helpful.

Answered: core.unify doesn't handle maps correctly

Sun, 29 Sep 2024 21:02:56 +0000

I've got the following patch for consideration. it works in two phases:
1. It identifies any keys which are "not complex". Complex here meaning a variable, or some kind of collection. These are keys that presumably can be matched on equality and not need unification. Probably the most common type.
2. Complex keys that need unification and backtracking.

I think there might be one weakness in the patch in that it considers x to be a template and y to be the concrete values and this is not true.

diff --git a/src/main/clojure/clojure/core/unify.clj b/src/main/clojure/clojure/core/unify.clj
index a89db73..c53a0c7 100644
--- a/src/main/clojure/clojure/core/unify.clj
+++ b/src/main/clojure/clojure/core/unify.clj
@@ -101,6 +101,36 @@
   (and (composite? form)
        (#{'&} (first form))))
 
+(defn- garner-unifiers-map
+  [uv-fn variable? x y binds]
+  (let [complex-key? (some-fn variable? composite?)
+        concrete-ks  (->> x keys (filter (complement complex-key?)))
+        simple-binds (reduce (fn [binds k]
+                               (garner-unifiers uv-fn variable?
+                                                (find x k)
+                                                (find y k)
+                                                binds))
+                             binds
+                             concrete-ks)]
+    (if (or (nil? simple-binds) (every? (complement complex-key?) (keys x)))
+      simple-binds
+      (letfn [(solve [x y binds]
+                (let [x' (first x)]
+                  (when-let [sol (reduce (fn [_ kv]
+                                           (when-let [binds (garner-unifiers uv-fn variable? x' kv binds)]
+                                             (when-let [binds (garner-unifiers-map
+                                                                uv-fn variable?
+                                                                (dissoc x (key x'))
+                                                                (dissoc y (key kv))
+                                                                binds)]
+                                               (reduced binds))))
+                                         nil
+                                         y)]
+                    sol)))]
+        (solve (apply dissoc x concrete-ks)
+               (apply dissoc y concrete-ks)
+               simple-binds)))))
+
 (defn- garner-unifiers
   "Attempt to unify x and y with the given bindings (if any). Potentially returns a map of the 
    unifiers (bindings) found.  Will throw an `IllegalStateException` if the expressions
@@ -117,6 +147,8 @@
       (variable? y)             (uv-fn variable? y x binds)
       (wildcard? x)             (uv-fn variable? (second x) (seq y) binds)
       (wildcard? y)             (uv-fn variable? (second y) (seq x) binds)
+      (and (map? x) (map? y))   (when (= (count x) (count y))
+                                 (garner-unifiers-map uv-fn variable? x y binds))
       (every? composite? [x y]) (garner-unifiers uv-fn
                                                  variable?
                                                  (rest x) 
diff --git a/src/test/clojure/clojure/core/unify_test.clj b/src/test/clojure/clojure/core/unify_test.clj
index a96d476..57a27da 100644
--- a/src/test/clojure/clojure/core/unify_test.clj
+++ b/src/test/clojure/clojure/core/unify_test.clj
@@ -100,3 +100,28 @@
     (is (= {} (unify '[1 ?x] '[1])))
     (is (= {} (unify '[1 ?x ?y ?z] '[1])))))
 
+
+(deftest map-order
+  (testing "Map unification is not sensitive to array map order"
+    (is (= '{?a 1, ?b 2} (unify '{:a ?a :b ?b} {:a 1 :b 2})))
+    (is (= '{?a 1, ?b 2} (unify '{:a ?a :b ?b} {:b 2 :a 1})))
+    (testing "including when keys are unified"
+      (is (= '{?a 1, ?b :b} (unify '{:a ?a ?b :b} {:a 1 :b :b})))
+      (is (= '{?a 1, ?b :b} (unify '{:a ?a ?b :b} {:b :b :a 1})))))
+  (testing "handles collisions in keys"
+    (let [kws #{:a :b :c :d :e :f :g :h :i :dCv :wxW}]
+      (is (= '{?a 1} (unify (zipmap kws (repeat '?a))
+                            (zipmap kws (repeat 1)))))
+      (is (= '{?a 1} (unify (zipmap (reverse kws) (repeat '?a))
+                            (zipmap kws (repeat 1)))))))
+  (testing "Backtracks on complex keys"
+    (is (= '{?a 1, ?b 2, ?c 3, ?d 3, ?e 4}
+           (unify '{?a [?b ?c]
+                    ?d [?e ?e]}
+                  {1 [2 3]
+                   3 [4 4]})))
+    (is (= '{?a 1, ?b 2, ?c 3, ?d 3, ?e 4}
+           (unify '{?a [?b ?c]
+                    ?d [?e ?e]}
+                  {3 [4 4]
+                   1 [2 3]})))))

clojure.data.priority-map's IKVReduce implementation doesn’t support `reduced`

Sat, 28 Sep 2024 23:52:55 +0000

Hi folks!

Just a heads-up that clojure.data.priority-map’s IKVReduce implementation doesn’t support reduced.

The current implementation (v1.2.0, 2024-02-19):

clojure.core.protocols/IKVReduce
(kv-reduce [this f init]
  (if keyfn            
    (reduce-kv (fn [a k v] (reduce (fn [a v] (f a v (item->priority v))) a v))
      init priority->set-of-items)
    (reduce-kv (fn [a k v] (reduce (fn [a v] (f a v k)) a v))
      init priority->set-of-items)))

But the nested reduce means that something like this’d be needed:

(defn- convey-reduced [x] (if (reduced? x) (reduced x) x))

clojure.core.protocols/IKVReduce
(kv-reduce [this f init]
  (if keyfn            
    (reduce-kv (fn [a k v] (reduce (fn [a v] (convey-reduced (f a v (item->priority v))) a v)))
      init priority->set-of-items)
    (reduce-kv (fn [a k v] (reduce (fn [a v] (convey-reduced (f a v k)) a v)))
      init priority->set-of-items)))

Note that the issue affects only (reduce-kv a-priority-map …), not (reduce a-priority-map …).

Thanks, cheers! :-)

Answered: core.unify run-tests.sh file has an error

Sat, 28 Sep 2024 17:11:54 +0000

Fixed. Thanks for the heads up. I used 1.11.4 and updated :1.10 to 1.10.3.

Answered: clj -X:deps find-versions prefers git deps if both git and mvn exist

Tue, 17 Sep 2024 02:44:25 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-268

Answered: The cljs docstring of `clojure.core.async/promise-chan` does not mention that it returns the value repeatedly

Thu, 29 Aug 2024 16:56:15 +0000

Thanks, an oversight. Fixed in core-async master now.

Answered: tools.reader parse-symbol is too sloppy when reading new n-dimensional class array

Thu, 22 Aug 2024 14:42:35 +0000

Ticket created
https://clojure.atlassian.net/browse/TRDR-74

Answered: data.json :date-formatter does not support all the formats Cheshire :date-format does due to using Instant internally

Sat, 10 Aug 2024 19:44:32 +0000

Answer provided by @cddr on Slack:

Use .withZone on the DateTimeFormatter itself to provide a timezone, and then the original format works just fine with clojure.data.json:

{:date-formatter (-> (DateTimeFormatter/ofPattern "MMMM, dd yyyy HH:mm:ss Z")
                     (DateTimeFormatter/.withZone ZoneOffset/UTC))}

(or (ZoneId/systemDefault) or similar).

This completely solves the problem, without changes to clojure.data.json.

Answered: Allow specifying aliases in coordinates that point to deps.edn projects

Thu, 08 Aug 2024 10:23:08 +0000

I just stumbled upon this very same old tools.deps issue myself with a Polylith workspace recently, when I decided to factor out a few sub-projects into Polylith workspaces of their own. But, since poly has a convention to keep all dev-time dependencies under the :dev alias, things didn’t click (quite obviously), so I had to duplicate them under the :deps key.

I’m now thinking about patching the tools.deps and using a patched version locally solely for this project.