Clojure Q&A - Recent questions and answers in Clojure

Answered: Optimize `eduction`

Sun, 05 Apr 2026 21:50:04 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2953

Answered: "Nested" vs "lateral" exception causes

Sun, 05 Apr 2026 21:46:32 +0000

I'm not sure this problem is common enough to warrant solving in core or extending the existing ex-info. If you are trying to throw a map bundling multiple exceptions, this really seems like a data problem more than an exception problem, and we have plenty of ways to bundle data into the ex map.

In Java, the typical solution for (one) lateral exception is to use ExecutionException, doesn't handle multiple though.

Answered: Destructuring {:as opts} unexpected behaviour with seq

Sun, 05 Apr 2026 02:22:50 +0000

A lot of this can be broadly considered "garbage-in, garbage-out". {:as opts} is map destructuring and so if you give it a non-map, you'll get undefined behavior.

In particular, try these expressions on Clojure 1.10 and you'll see that many of them throw exceptions.

Clojure 1.11 introduced a new meaning for some key/value destructuring -- see https://clojure.org/news/2021/03/18/apis-serving-people-and-programs -- which changed the undefined behavior, in order to support new use cases.

Bottom line: pass a non-map to map destructuring and you are in undefined behavior territory. It just happened to change between 1.10 and 1.11 so that some cases that threw exceptions now just produce "junk" instead.

Answered: requiring an empty .clj without an alias should fail as with an alias

Thu, 02 Apr 2026 20:41:10 +0000

Logged:
https://clojure.atlassian.net/browse/CLJ-2951

And one for compile:
https://clojure.atlassian.net/browse/CLJ-2952

Answered: Is taggedliteral's equality check inefficient?

Tue, 31 Mar 2026 19:58:35 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2950

Answered: Optimized str function

Sun, 29 Mar 2026 08:47:19 +0000

I've done some independent exploration of the options space for optimizing str which does not involve anything ground shattering but still gives good performance improvements

variadic arities (up to 20, yuck) will probably give the best performance. Can settle for common cases like up to 5 (apply str will still suck but whatever)
using reduce instead of a loop (would probably require redefining str or providing a str1 with the old impl for bootstrap purposes)
using inline meta, orthogonal to all other options

Additionally, having a function like str which only takes a sequence and reduces over it could provide a better code path than (apply str xs)

Similar work has been done in spork and stringer

Why doesn't defn also implicitly name the anonymous function it defines for recursion?

Sat, 21 Mar 2026 13:49:43 +0000

Why doesn't defn implicitly name the function to create a named recursion point?

(clojure.walk/macroexpand-all
  '(defn foo [x]
     (foo x)))
; =>
(def foo
  (fn*
    ([x]
     (foo x))))

This could instead expand to

(def foo
  (fn* foo ; note the foo here
    ([x]
     (foo x))))

How it works right now, foo resolves to a global var #'foo, which is created when the (def ...) form is analyzed. In the second case, it resolves directly to the function object. Thus, it should save us a var dereference at runtime in this case.

EDIT: Found out, this is exactly what direct linking is used for.

Controlled Bailout, Jira issue 2213

Sat, 21 Mar 2026 10:14:48 +0000

I would like to improve Issue 2213 as follows. Do you think, this makes sense? Shall I become contributor for this?

The new description would be:

When developing Input-Process-Output tools I am often in the situation, that I have a sequence of activities (e.g. opening a file, spec checking a file, calling external tools, creating files), which each could fail in certain ways. Clojure does not have a good way to control such a sequence of activities in a way that all sorts of things, which could go wrong, can be handled comfortably. In imperative programming languages concepts like early exit or bailout are used. These are not not very functional. Unfortunately practical problems are often like this.

The issue is a bit more general and a solution would be nice not only for those who develop such sort of tools. So I can give a simple example.

(let [config-file (get-file-from-network xy)
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

As all these steps can fail, we could instead implement it like this.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file))))

Now the code has suffered already a lot. The sequential nature of the problem is lost. And it is not even doing what we need. We have to report to the user what went wrong.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file)
      :file-has-syntax-errors)
    :file-not-valid-edn)
  :file-cannot be openned)

But this is still not doing what we need. We have to provide more information about each failure. If a file cannot be openned, is it because the file does not exist or we do not have read permissions? And what did the spec check tell us? So we cannot just use nil as a universal failure. We must deliver more information when failing. And we cannot use if-let, either. So we are not even done.

This problem report asks for a better solution for this conceptual challenge.

This example depicts a conflict that should not happen when using an appropriate programming language: First we are able to quickly make a prototype. But in the end the final code has not much in common with the first code any more. The final design is not driven by the problem domain, but by the technical need for an error handling. The need for a bailout mechanism in this example imposes too many huge code changes.

The principal problem with all these solutions is that they coerce a sequence of actions into something which is not a sequence. If your problem is a sequence, then the implementation should also be a sequence.

Idea: Exceptions

As an alternative implementation I went with Exceptions. But it feels wrong, because I am talking about things, that are expected to fail. I cannot just use the Exceptions that are comming out of Java for example when opening a file for read. I need detailed information, what went wrong. If you are a command line tool, it is expected from you, that you provide good error messages. I ended up catching and rethrowing exceptions everywhere in the program.

Idea: Like for/doseq

For me I created a small macro, that extends let. Then I use this syntax:

(let [[config-file error] (get-file-from-network xy)
      :escape     error
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This often allows a surprisingly intuitive code. For example here:

(let [[config-file error-code] (get-file-from-network xy)
      :escape     (if (= error-code :does-not-exist) 
                    :file-xy-does-not-exist)
      :escape     (if (= error-code :io-error)
                    :file-xy-cannot-be-read)
      [config-file error-code] (parse-edn config-file)
      :escape     (if error-code :file-xy-not-legal-edn)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This is inspired by the for/doseq. But I don't claim that this is a good solution for Clojure (although I think so). But I think, the let macro is a good candidate when improving how Clojure can be used for such imperative things.

Idea: Using `if-let`

I also investigated the solution, that was originally proposed by this issue.

(if-let [config-file (get-file-from-network xy)
         config-file (parse-edn config-file)
         config-file-ok? (spec-check config-file)]
  (do-something-with config-file)
  :error)

This problem with this solution is that none of the bindings are available in the else part. That makes it very hard to react accordingly. This is a nice and small new language feature. But I don't think, that in practice it would be of help so often. The example from the original issue was very artificial with mathematical operations that cannot fail. The first draft of this issue with that artificial example does not actally describe a real problem. That is why this issue has completelly been rewritten.

Or course we could still bind everything, which was not failed. But I don't think, we would want that. It would have very interesting consequences to the compiling model.

Idea: Threading macros

As this issue is a about a sequence of activities, a new type of threading macro (e.g. let->) could also be an intuitive solution. But I have not tried anything like this.

Final Words

The principle challenge is, that all these solutions establish a sort of alternative control flow. It is a hard challenge to do this right, especially in a functional language. Like exceptions, that immediatelly exit and magically jump somewhere else. Clojure as a practically language could address this challenge.

Answered: Evaluating forms using eval can create a valid undesirable recursion point

Tue, 17 Mar 2026 15:46:56 +0000

I logged this as https://clojure.atlassian.net/browse/CLJ-2947 but I don't think it's a big deal.

Answered: It's difficult to figure out options I can pass to slurp function.

Fri, 27 Feb 2026 15:11:56 +0000

This is fair. I created https://clojure.atlassian.net/browse/CLJ-2944 to track this.

Answered: Is it legal for a namespace to start with a number?

Mon, 23 Feb 2026 19:12:09 +0000

As far as I can tell, there is no reason a namespace segment other than the first can't start with a number.

Feature Request:Make anonymous fn/reify class name IDs per namespace instead of one global counter

Wed, 18 Feb 2026 15:34:38 +0000

Compiled anonymous functions and reify classes get names like ns$fn__4532, where the numeric suffix comes from a global AtomicInteger counter
(RT.nextID()).

This counter is shared across the entire runtime and is consumed by fn classes, reify classes, constants tables, gensyms, etc.

The problem is that because the counter is global, any code change shifts the IDs for everything compiled after it. This makes profiling across builds
really painful, you can't meaningfully compare flame graphs because all the class names change even in code you didn't touch.

I'd like to propose scoping the ID counter per-namespace instead. Since the namespace is already part of the class name prefix, uniqueness is still
guaranteed. This would eliminate the cascading effect across unchanged namespaces and make profiling diffs actually useful.

I'm not sure what's the downsides of this, but from what I saw of AtomicInteger, it isn't used a lot to break things.

Thank you!

Answered: Is it valid for metadata to have metadata?

Tue, 17 Feb 2026 15:10:58 +0000

Thanks for the additional info! I do think this is bug, which I've filed at https://clojure.atlassian.net/browse/CLJ-2941 and patch is welcome.

If you need to sign the contributor agreement or get access to jira, please follow process at https://clojure.org/dev/dev#_becoming_a_contributor

Answered: bit-count in cljs but not clj

Fri, 30 Jan 2026 14:20:06 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2937

definterface doesn't expose gen-interface's :extends for interface extension

Mon, 26 Jan 2026 19:49:08 +0000

gen-interface allow :extends to specify one or more interfaces, which will be extended by this interface.

definterface doesn't expose this.

Use case is working with primitives (where protocols don’t help), to get things to dispatch nicely in a zero boxing primitive transducer implementation.

Answered: How to force clojure.spec generator to skip a field

Thu, 15 Jan 2026 10:26:11 +0000

Given that you're using gen/let, why not just this?

(gen/let [x (s/gen (s/keys :opt [::a]))
          y (s/gen (s/keys :opt [::a]))]
  {:x x
   :y (cond-> y (not (contains? x ::a)) (dissoc ::a))})

Alternatively:

(gen/let [x (s/gen (s/keys :opt [::a]))
          y (s/gen (cond-> (s/keys :opt [::a])
                     (not (contains? x ::a))
                     (s/and #(not (contains? % ::a)))))]
  {:x x
   :y y})

Answered: Is invoking an anonymous primitive function expected to use the primitive interface?

Tue, 13 Jan 2026 22:47:58 +0000

Reviewing this it appears to be the same issue as cannot-create-anonymous-primitive-functions which tracks with this jira CLJ-919

Answered: clojure.core/subs should use type hints of ^CharSequence, NOT ^String

Tue, 13 Jan 2026 19:06:31 +0000

Created jira and patch at https://clojure.atlassian.net/browse/CLJ-2936

Answered: Literals for Unicode code points (and perhaps also sequences thereof)

Mon, 12 Jan 2026 22:26:24 +0000

Created feature request jira https://clojure.atlassian.net/browse/CLJ-2935

Answered: Reader docs say foo.bar is a qualified symbol but qualified-symbol? is false

Mon, 12 Jan 2026 22:08:25 +0000

"Qualified" means more than one thing depending on context. Java classes are "qualified" by their package name. symbols are "qualified" by their namespace. class names are syntactically represented by a symbol which has overlapping senses - the class package is a dotted prefix that lives in the "name" part of the symbol.

qualified-symbol? is specifically referring to namespace qualification.

My guess is that Rich would say that the original sentence is correct and written as intended.

Answered: CVE-warning in org.fressian/fressian <- org.clojure/data.fressian

Fri, 09 Jan 2026 16:31:43 +0000

I agree that this is a false positive. Neither org.fressian/fressian nor org.clojure/data.fressian depend on either Datomic or h2, either explicitly or implicitly, even via test deps, so not sure how that could be possible even via test deps.

clj-watson depends on https://github.com/dependency-check/DependencyCheck to do its checks, and you can report false positives as an issue on its issue tracker https://github.com/dependency-check/DependencyCheck/issues.

Answered: Why does the REPL incorrectly display my command after I press enter?

Tue, 23 Dec 2025 08:15:40 +0000

Updating the version of rlwrap by building it from source fixed the issue.

The version installed on my FreeBSD system was 0.45, the latest version available for the package manager, building from source yielded version 0.48, which seems to have fixed the display bug :)

Octal escape sequence decoding in strings does not stop at non-octal digit

Thu, 18 Dec 2025 09:35:53 +0000

Strings suppose to support standard Java escape sequences, including octal escape sequence: [0-7]{1,3}

In Java decoding of octal sequences stop at the first non-octal digit or any other character if there are 1 or two octal digits in the escape sequence. For example:

jshell> "\18"
$1 ==> "\0018"

But Clojure reads up to 3 potentially octal digits greedily resulting in wrongly consuming non-octal digits:

Clojure 1.12.4
user=> "\18"
Syntax error reading source at (REPL:1:5).
Invalid digit: 8

non-octal characters:

Clojure 1.12.4
user=> "\1d"
Syntax error reading source at (REPL:1:5).
Invalid digit: d

And succeed only when there is line terminator or exact three octal digits in supported octal range:

Clojure 1.12.4
user=> "\1"
""
user=> "\1"
""
user=> "\12"
"\n"
user=> "\123"
"S"
user=> "\123d"
"Sd"

Answered: [clojure.edn] Leading zeros in numbers

Mon, 15 Dec 2025 20:05:17 +0000

Leading zeroes in Clojure should largely follow the lead of Java when the reference is unclear:

Long - multiple leading 0s allowed, treated as octal
BigInteger - multiple leading 0s allowed, treated as decimal in Java BigInteger, octal in Clojure (this is a difference, but supported by the reader reference page)
Double - multiple leading 0s allowed in either whole number part of exponent, treated as decimal
BigDecimal - multiple leading 0s allowed, treated as decimal

With respect to edn, there are additional constraints - octal is not supported, and leading 0s not allowed in integers, but are allowed in decimal whole and exponents by my reading. I do not see support for your assertion "even for floats" - the constraint is listed only for integers).

Thus I would expect that any leading 0s in an integer (with or without N suffix) should be invalid, yet they are all read as octal. So that seems like a potential bug. Because clojure.edn is a superset of edn, you could potentially contend this is additive syntax/semantics beyond edn but seems a little confusing.

For floating points, by my reading, leading 0s in whole or exponent parts are allowed, so no issue or difference from Clojure or Java there afaict.

Answered: `find` docstring enhancement proposal

Thu, 11 Dec 2025 20:35:32 +0000

See https://clojure.org/reference/data_structures#Maps (and other places on that page) where "entry" is referred to and, in particular:

"...a sequence of map entries, which are key/value pairs"

See also https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Map.html where "entry" is referred to several times and also defined as a key/value pair.

Searching the web for map entry -java seems to indicate this is pretty common terminology in other languages as well.

Answered: Aliased namespace in tagged literal

Thu, 11 Dec 2025 20:18:34 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2932

I reworded the title and problem as this slips into solution space (and I'm not sure that solution is even possible given the reader nature of the problem).

Answered: clojure.edn and clojure allows keywords with empty ("") namespaces

Tue, 09 Dec 2025 22:55:20 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2931

Other old and related JIRAs for relevance: CLJ-1286 CLJ-1252

Answered: Why is `list` defined with a RestFn instead of `create` method?

Tue, 09 Dec 2025 22:44:08 +0000

Probably only known to Rich, don't think these inconsistencies are important.

Answered: bug bigdec

Tue, 09 Dec 2025 22:36:21 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2930

Answered: not-found arg for invoking set (and vector)?

Sat, 06 Dec 2025 19:46:50 +0000

Dupe of https://ask.clojure.org/index.php/2833/optional-found-argument-when-invoking-vectors-sets-functions - please vote there if you're interested, happy for someone to refresh the jira+patch on https://clojure.atlassian.net/browse/CLJ-1305 too.

Answered: Double colon ("::") in the middle or at the end of identifier.

Tue, 02 Dec 2025 16:47:37 +0000

Don't know, sorry.

Answered: Support characters beyond basic multilingual plane

Tue, 02 Dec 2025 16:42:47 +0000

That line you linked is specifically for reading an individual character value (like \a) - as a single character it's not possible to represent both parts of a surrogate pair, so this seems correct (a Java char is an int).

However, you can use surrogate pairs in strings, which is how you would most commonly use them, and that works fine.

$  clj
Clojure 1.12.3
user=> "\ud83d\ude0d"
""

I believe surrogate pairs are not currently allowed in symbols or keywords, that's maybe something that could be extended in the future, but I haven't seen anyone looking for that yet.

Answered: Typo in clojure.zipper/zipper docstring

Tue, 25 Nov 2025 20:32:58 +0000

Good catch! Logged as https://clojure.atlassian.net/browse/CLJ-2929

Answered: clojure.edn/read invoke user-supplied reader functions when tagged literal is to be discarded by discard macro

Tue, 25 Nov 2025 20:22:21 +0000

This is definitely an appropriate thing to put on Ask Clojure and seems like a bug in the impl of the spec to me.

Logged as https://clojure.atlassian.net/browse/CLJ-2928

Answered: Docstring clojure.edn/read-string is misleading

Tue, 25 Nov 2025 20:14:35 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2927

Answered: Could we get deref support on ScopedValue?

Tue, 25 Nov 2025 20:00:22 +0000

Logged as https://clojure.atlassian.net/browse/CLJ-2926

Answered: Inconsistent errors in ratio parsing with either `clojure.edn/read` or `clojure.core/read`

Tue, 25 Nov 2025 19:43:36 +0000

Ratios in Clojure are rational ratios with integer numerator and denominator. Ratio syntax is not a composite of integer or other numeric syntaxes, it is its own definition where the numerator and denominator are strings of digits of arbitrary length (treated as long or biginteger as necessary based on scale).

The syntax is semantically defined as:
sign? digit+ '/' digit+

The regex pattern is currently:
"([-+]?[0-9]+)/([0-9]+)"

This pattern incorrectly allows leading 0 and should be narrowed.

Filed jira at https://clojure.atlassian.net/browse/CLJ-2925

The other errors are expected and these syntaxes are not supported.

Answered: Multiple Java types cannot be idiomatically leveraged w/o proper `IDeref` support

Mon, 24 Nov 2025 20:55:02 +0000

Probably tough to make it a protocol now, especially with backward compiled compatibility.

It would be best to vote on the question for Optional to voice your opinion there - we look at higher voted things with more urgency.

ScopedValue is only available non-preview in 25, so pretty new still. would probably be best to file an Ask question specifically about that so it can gather votes.

LazyConstant is not a thing yet, so will be a long while probably.

Answered: Support for automatic promotion to BigDecimal in +', *', etc.

Mon, 17 Nov 2025 15:28:28 +0000

I think this is not a bug and is by design - the auto-promotion operators only have promotion semantics for integer arguments, not for floats.

The only relevant reference page here is https://clojure.org/reference/data_structures#_longs - it's important to note that this is in a header called "Longs" and only mentions promotion for integer types:

Clojure provides a set of alternative math operators suffixed with an
apostrophe: +', -', *', inc', and dec'. These operators auto-promote
to BigInt upon overflow, but are less efficient than the regular math
operators.

I went back and did some digging from when numerics were overhauled (Clojure 1.3). The design docs from this time can be found in these wayback links that provide more context and align with the semantics above:

The promotion op docstrings are currently not very helpful in understanding this (see CLJ-2923 ).

Answered: Multimethod does not consistently resolve methods in a diamond-like hierarchy

Tue, 11 Nov 2025 12:58:24 +0000

FWIW, we might have encountered this issue in Manifold.

Answered: cannot call Java Constructor overload

Mon, 03 Nov 2025 18:35:22 +0000

That constructor is private, you can't call it.

Answered: Macro expansion lose type hints

Mon, 03 Nov 2025 14:30:41 +0000

I believe this is the same general problem as https://clojure.atlassian.net/browse/CLJ-865, which has been long-debated in the core team.

Unwrapped do is treated as a special form in let and fn bodies

Fri, 24 Oct 2025 17:30:35 +0000

when a let or fn body begins with the bare symbol do (not in list head position) it is treated as a do-block wrapper for the rest of the body

Clojure 1.12.0
user=> (let [] do)
nil
user=> (let [] do 123)
123
user=> (let [] 123 do)
Syntax error compiling at (REPL:1:1).
Unable to resolve symbol: do in this context
user=> ((fn [] do))
nil

Aside from being unexpected, it also has the effect of appearing to override any local binding named 'do':

user=> (let [do :something] do)
nil

Note that Clojurescript treats all the above cases 'correctly':

ClojureScript 1.11.132
cljs.user=> (let [] do)
                    ^
WARNING: Use of undeclared Var cljs.user/do at line 1
nil
cljs.user=> (let [do :something] do)
:something

The community guide at https://clojure-doc.org/articles/language/macros/
has pointed out this exact edge case (since 2013?) and recommends to 'Never use special names as local binding or global variable names'. However it seems like a bug worth addressing given the discrepancy between JVM/CLJS outputs

Answered: The docstring on empty? should perhaps not recommend using seq instead anymore

Fri, 17 Oct 2025 14:13:15 +0000

The docstring says "To check the emptiness of a seq..." which is still the preferred idiom.

`(s/gen ...)` caches its failure to load generators and thus is incompatible with `add-lib`

Tue, 23 Sep 2025 16:23:58 +0000

Clojure 1.12.0
user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/def ::x #{1 2 3})
:user/x
user=> (s/gen ::x)
Execution error (FileNotFoundException) at user/eval145 (REPL:1).
Could not locate clojure/test/check/generators__init.class, clojure/test/check/generators.clj or clojure/test/check/generators.cljc on classpath.
user=> (add-lib 'org.clojure/test.check)
[org.clojure/test.check]
user=> (s/gen ::x)
Execution error (FileNotFoundException) at user/eval145 (REPL:1).
Could not locate clojure/test/check/generators__init.class, clojure/test/check/generators.clj or clojure/test/check/generators.cljc on classpath.

Improve javadoc especially for tool usage

Tue, 16 Sep 2025 17:54:13 +0000

In order to provide a hot key in VS Code to show the JavaDocs associated with a selected form (class name or the type of an expression), I wrote the following Joyride script:

https://github.com/seancorfield/vscode-calva-setup/blob/develop/joyride/scripts/javadoc.cljs#L15

This highlights three issues that could be addressed/improved:

On JDKs later than 15, the javadoc machinery falls back to JDK 8, unless you explicitly call add-remote-javadoc for at least java. and javax.. This is a known issue that should be addressed in Clojure 1.13 per https://clojure.atlassian.net/browse/CLJ-2920 -- hopefully it will assume the URL structure for JDKs going forward so we don't run into this problem again, unless Oracle changes their URL structure again (hopefully, unlikely).
javadoc-url is private so tools have to use #' to access it, which makes it feel like this is just an implementation detail and subject to change. It would be nice for tools if this was part of the public, documented API for clojure.java.javadoc.
Inner classes are not handled well. If you ask for the javadoc-url for java.util.Map$Entry, you get a URL with Map$Entry.html which doesn't exist. Since inner classes are documented in their outer class, removing $[a-zA-Z0-9_]+ from the class name or from the URL would really help here.

Here's an example REPL session for Clojure 1.12.2 on JDK 24, showing these issues:

user=> (clojure-version) "1.12.2" user=> (require 'clojure.java.javadoc) nil user=> (#'clojure.java.javadoc/javadoc-url "java.util.concurrent.ExecutionException") "http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutionException.html" user=> (#'clojure.java.javadoc/javadoc-url "java.util.Map$Entry") "http://docs.oracle.com/javase/8/docs/api/java/util/Map$Entry.html" user=>

clojure -X hangs with agent use

Wed, 10 Sep 2025 21:02:32 +0000

Given this repro:

(ns repro)

(defn exec-fn [_]
  (let [a (agent nil)]
    (prn (-> (java.lang.ProcessHandle/current) (.pid)))
    (send a (fn [_] 3))))

the clojure -X repro/exec-fn invocation is hanging.

This seems to be unintentional, given that clojure -X doesn't wait for futures to finish either?

Answered: Do you use arity 3 or higher comparisons such as = < <= > >= == in performance sensitive code?

Tue, 12 Aug 2025 21:31:07 +0000

Yes, I use 3-arity inequality functions with some regularity, much like PostgreSQL's BETWEEN operator, I've also seen it used by others. I think the most frequent use case for this is in tests for me personally but some of these are inside ares that can get large, so I would appreciate a performance optimization.

I would also agree that 4+ arity is exponentially rarer than 3-arity (I've never seen it in practice, but I assume there's been at least one person who has done (apply > coll) at some point to check if a collection is sorted), but I have no data on this beyond anecdotal experience.

Answered: core.async docstrings for `take!` and `put!` not clear on impact of `on-caller?`

Tue, 12 Aug 2025 14:32:22 +0000

Including the docstring here for reference:

Asynchronously takes a val from port, passing to fn1. Will pass nil if
closed. If on-caller? (default true) is true, and value is immediately
available, will call fn1 on calling thread.

fn1 may be run in a fixed-size dispatch thread pool and should not
perform blocking IO, including core.async blocking ops (those that end
in !!).

The docstring is promising what will will happen if on-caller? is true and the value is immediately available. When those conditions are not met, there are no promises being made. The actual implementation has changed over time and may change again to optimize performance.

Answered: specifying `:let` as the first element of `for` causes an macro expansion error

Mon, 11 Aug 2025 01:09:48 +0000

Seems like it is working as intended per the docstring.