Clojure Q&A - Recent questions tagged request

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!

Core Cache and Count

Wed, 28 Jan 2026 16:54:22 +0000

Hi,

I notice that in the wrapped namespace of core.cache, there is a has? function that checks the wrapped cache if it has an element or not. It does this by delegating to the underlying cache c/has? function of the wrapped cache.

For reporting purposes, I need to get the current size of the cache (with the caveat of course that the size could be approximate, given the particular nature of a particular cache - but approximation is fine).

Unfortuantely, a size or count function doesn't exist in the wrapped namespace, it only exists on the wrapped cache itself - thus doing:

(count @wrapped-cache)

does return the value.

It would be good, however, if there was also a similar function in the wrapped namespace, something like this (using size as the function name, but could be something else):

(defn size
   [cache-atom]
   (c/count @cache-atom)

The rationale being that having this function exposed in the wrapped namespace keeps the code consistent - i.e., whilst I can continue to do:

(count @wrapped-cache)

It would more preferrable to keep using the wrapped namespace (as I do with other operations, such as evict), i.e., something along the lines of:

(wrapped/size wrapped-cache)

Do you think this suggestion might be something that could be included in the wrapped namespace?

Thank you.

-=david=-

Improving curl options for CLI install scripts (brew-install)

Mon, 26 Jan 2026 12:39:44 +0000

Hi!

I'm the maintainer for Heroku's Clojure buildpack. It uses the install scripts from clojure/brew-install to install the CLI. I noticed intermittent install failures related to the download of the Clojure tools. I believe most of them could be avoided with a slightly changed curl command line options.

I opened a PR before realizing that PRs will not be accepted, so I'm starting this thread to properly get the discussion going. For reference, the closed PR can be found here: https://github.com/clojure/brew-install/pull/10

I believe these options would improve the download behaviour for all users, but especially when used in automations:

--connect-timeout 3 (https://curl.se/docs/manpage.html#--connect-timeout)
Prevents hanging when server is unreachable.

--fail (https://curl.se/docs/manpage.html#-f)
Exit with error code 22 for HTTP responses with status codes >= 400.

--max-time 60 (https://curl.se/docs/manpage.html#-m)
Maximum time in seconds for the entire transfer operation. Prevents hanging indefinitely with slow connections.

--no-progress-meter (https://curl.se/docs/manpage.html#--no-progress-meter)
Introduced in curl 7.67.0 (Nov 2019). Disables the progress bar for cleaner output. But less drastic than --silent and will still output diagnostic information (i.e. retries).

--retry-max-time 60 (https://curl.se/docs/manpage.html#--retry-max-time)
Retry only within this time period (60 seconds). After this time expires, no more retries will be attempted.

--retry 5 (https://curl.se/docs/manpage.html#--retry)
Introduced in curl 7.12.3 (Dec 2004). Retry up to 5 times on transient errors (timeouts, HTTP 408, 429, 500, 502, 503, 504, 522, 524).

--retry-connrefused (https://curl.se/docs/manpage.html#--retry-connrefused)
Introduced in curl 7.52.0 (Dec 2016). Consider connection refused as a transient error for --retry.

These are obviously opinionated and my ask is not for these options specifically. Happy to get anything that will improve the situation. :)

Manuel

Could we get deref support on ScopedValue?

Tue, 25 Nov 2025 16:26:47 +0000

Following on from this, and since Optional is already being considered, I would like to propose that ScopedValue is considered as well. It is now a standard feature on an LTS release (i.e. 25).

As always, thanks in advance...

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

Mon, 10 Nov 2025 04:15:47 +0000

Is there support for BigDecimal promotion in the +', *', etc. clojure.core functions?

When I run the following code in the REPL:

(* 2 Double/MAX_VALUE)     ;; ##Inf, Doesn't auto-promote as was expected.
(*' 2 Double/MAX_VALUE)    ;; ##Inf, Expected that it would auto promote.

Following cases also didn't work:

(*' Double/MAX_VALUE 2)        ;; ##Inf, Moving around the arguments.
(*' 2.0 Double/MAX_VALUE)      ;; ##Inf, Using a Double literal instead.
(*' Double/MAX_VALUE 2.0)      ;; ##Inf
(*' Double/MAX_VALUE 2.0M)     ;; ##Inf, Using a BigDecimal literal instead.
(*' 2.0M Double/MAX_VALUE)     ;; ##Inf

I decided to check the Clojure compiler source for promotion, and based on my limited understanding of the code I see that DoubleOps is using the implementation of addP of OpsP abstract class (which just calls the normal add function) while there is one present for LongOps which can be found here.

Is this a bug? And if yes, I would like to work on the fix and I'll check the Development page of Clojure to do the needfull.

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

Tue, 28 Oct 2025 11:41:48 +0000

A fresh clojure library clojure.java.doc introduces some nice functions for querying javadoc.
It all seems nice and useful, I really can't complain (nor this is high priority to me since Javadoc is usually so verbose that I would probably continue to read it in the Web browser unless I discover use cases where REPL access is more practical to me).

However, one thing that struck my mind, and I had to ask is this: why introduce new functions, such as jdoc? Wouldn't it be more convenient to introduce a protocol (say, doc) which could then be extended to support
1. original Clojure doc
2. Javadoc
3. some sort of javascript doc, if that exists
4. C# doc
5. Native libraries doc, etc.

I understand that doc is a part of Clojure core, which you avoid changing at any costs, but this protocol wouldn't have to touch it.

It could simply be a "replacement" from the new namespace, which would have one implementation that invokes doc, but also be open to other implementations, such as jdoc.

And I understand that for Clojure core it's an absolute priority to not even change a formatting of the source code unless it's absolutely necessary, to keep very detailed compilation behavior or whatnot. It's a choice you made, it has its traidoffs, you chose those, and that's it. But, are those tradeoffs the same for namespaces such as clojure.repl and functions such as doc?

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.

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

Tue, 02 Sep 2025 08:02:18 +0000

Hi! While reading the channel implementation I noticed the internal queue is a java.util.LinkedList:
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj

The common JVM guidance these days is to prefer java.util.ArrayDeque for FIFO/LIFO queues due to better locality and lower GC overhead. For example, the JDK docs state: “This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.”
https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html
Related SO discussion: https://stackoverflow.com/questions/6163166/why-is-arraydeque-better-than-linkedlist

A few questions for the maintainers:

Was LinkedList originally chosen for a specific reason (e.g., very old JDK compatibility)?
Are there behaviors in channels that specifically rely on LinkedList (e.g., allowing null, I believe channels disallow nil anyway, or particular iterator characteristics), or would ArrayDeque be a drop-in replacement for the add/remove-from-ends operations used?
If we provide a small PR and benchmark showing an improvement (lower allocations / better throughput under contention), would such a change be considered?
Since ArrayDeque is available on Java 8+, and current Clojure/core.async baselines target that or newer, is there any remaining compatibility concern?

Context: there was an older conversation in Clojurians (#clojure) that suggested ArrayDeque could reduce GC pressure under load and that the original choice may have been influenced by older JDKs:
https://clojurians.slack.com/archives/C03S1KBA2/p1526551888000376

If this sounds reasonable, I’m happy to run the core.async test suite, add JMH-style benchmarks focused on channel put/take hot paths, and submit a PR.

Thanks!

tools.build compile-clj capture out/err

Mon, 28 Jul 2025 19:41:29 +0000

When calling compile-clj, a user can pass in :out and :err to capture the output of the compilation call. However, if for some reason the sub-process exits with a non-0, compile-clj throws without returning that output, making it hard to know what went wrong. (see here: https://github.com/clojure/tools.build/blob/2d2f1b05fd84c3cc756221c17fcfb98034b4d65c/src/main/clojure/clojure/tools/build/tasks/compile_clj.clj#L120)

I would find it helpful if the ex-data of the thrown exception included the :out (variable ps-out and :err (variable ps-err) from the process/process call. Then I could have further insight into what went wrong.

How to pipe with clojure.java.process?

Fri, 04 Jul 2025 21:32:20 +0000

I'm sure this is embarrassingly simple, but I can't seem to figure out how to pipe stdout to stdin with clojure.java.process.

With clojure.java.shell, I could do something like

(sh "cat" "-" :in (:out (sh "echo" "hi")))

I realize this is an indirect way to handle this since it's blocking and is handling everything as strings instead of native Java objects.

With clojure.java.process, I could do something like

(exec "bash" "-c" "echo hi | cat -")

but that's just using Bash.

I know there are other, third-party libraries such as Babashka/process and Raynes/conch, but I'd like to learn how to do this with the new Clojure library.

My instinct was to try

(exec {:in (stdout (start "echo" "hi"))} "cat" "-")

or something to that effect, but it doesn't work.

`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.

File and location data on namespaces

Fri, 16 May 2025 14:46:20 +0000

Preamble

Two thoughts:

Namespaces are not tied to files; they can be created and removed as desired. However, both idiomatically and through clojure.core, they are typically tied to files, being specified at the top of a file that shares the same name: src/noahtheduke/splint/rules.clj holds a single namespace noahtheduke.splint.rules, which is declared before all other forms. This is enforced in require and use calls: (require '[noahtheduke.foo.bar :as fb]) will find a file at src/noahtheduke/bar.clj and then once the file is loaded will attempt to find the namespace noahtheduke.bar and raise an error if it does not exist.

In the compiler, DefExpr will add to the created var's metadata location data in the form of :line, :column, and :file. The first two come from the seq and latter from *file*. This allows for introspection and analysis from tooling, and for better error handling in exceptions and messages.

Desired functionality

I have a collection of namespaces. I want to slurp the corresponding files (if they exist) to analyze and modify with rewrite-clj.

Discussion

Right now, I use metadata on vars to find relevant objects in code and then find the file that way:

(defn get-path-from-var [var']
  (let [f (:file (meta var'))
        path (or (some-> f
                         (#(.. (Thread/currentThread)
                               (getContextClassLoader)
                               (getResource %)))
                         (io/file)
                         (str))
                 f)]
    {:path path
     :file (when (and path (.exists (io/file path)))
             (slurp path))}))

However, that requires users to use the defcram macro I've written, which limits the potential for inline-usage of my primary macro compare-output (such as in a deftest).

I want to be able to use *ns* in compare-output to potentially find where the macro is being called, so I can perform the analysis and desired diffing. This would most easily be done by having location metadata on namespaces.

But more importantly than just my library, I think having location metadata on namespaces would be a genuine help for many tools (such as eastwood, tools.namespace, CIDER, kibit, splint, etc).

Solutions

I'm only going to discuss one solution because this is an Ask, not a jira ticket lol.

I think adding the location metadata in the ns macro is the best place to put it. The ns macro is the preferred way to create a new namespace. Creating namespaces with in-ns or create-ns requires additional steps to make the namespace usable, and neither is a macro to hold &form metadata, increasing the work of adding location metadata.

`merge-with` doesn´t treat pair (vectors of 2) the same way `merge` does

Thu, 01 May 2025 11:25:20 +0000

;; merge
(merge {:a :b} [:a :c]) ;=> {:a :c}

;; merge-with
(merge-with (fn [_ x] x) {} {:a :b} [:a :c])
;; => class clojure.lang.Keyword cannot be cast to class java.util.Map$Entry

I think this happens because merge-with eventually calls seq on the "Map", expecting to get a "Map Entry" from which then it can extracts key and value, and fails when receiving a Vector, because seq will just yield one element at a time:

(key (first (seq {:a :c}))) ;; => :a
(key (first (seq [:a :c])))
;; => class clojure.lang.Keyword cannot be cast to class java.util.Map$Entry

I think it is justified to expect that (partial merge-with (fn [_ x] x)) should behave exactly as merge and my proposal is to make it happen, if what I described makes sense.

Thank you!

tools.cli: Support default value for arg with value

Mon, 28 Apr 2025 17:21:53 +0000

I would like to have a --diff flag which defaults to origin/HEAD but allow pass a different rev in the arg, like --diff origin/bar.

Context: https://clojurians.slack.com/archives/C03S1KBA2/p1745859358672599

regular expression with Classes for Unicode scripts, blocks, categories and binary properties

Tue, 22 Apr 2025 15:39:14 +0000

In Clojure, the following expression works fine:

(re-matches #"\p{Lu}" "Á") ;; => "Á"

But in Clojurescript, it returns nil.

It is not that Javascript doesn't support that kind of Unicode classess, but you have to activate them explicitly, whether in Java, they are activated by default.

E.g. In Javascript, the following code returns true:

/\p{Lu}/u.test("Á") // => true

But if I omit the Unicode flag (/u) I get false:

/\p{Lu}/.test("Á") // => false

I think this is probably because Clojure Script doesn't activates the Unicode flag for us.

If that the case, I think consistency between Clojurescript and Clojure could benefit a lot if the flag is activated by default.

Idiomatic way to use java.util.Optional

Mon, 07 Apr 2025 14:16:59 +0000

Is there an easy way to work with java.utils.Optional values in Clojure? I'm currently using 1.12 so I can say things like (Optional/.orElse foo nil) to convert the optional value to a "normal" value (X or nil), but that and other Optional methods are still sources of tension or boilerplate compared idiomatic Clojure constructs (some-> for example).

If such a way doesn't currently exist, can it be considered for addition to Clojure? Maybe opening up deref to work on Optionals as well.

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

Sun, 16 Feb 2025 18:43:21 +0000

At the moment (in 1.2.24) the pom.properties includes the current date in a comment, making the resulting jars differ. For now, in Debian we're deferring to SOURCE_DATE_EPOCH whenever it's set: https://salsa.debian.org/clojure-team/tools-build-clojure/-/blob/5739183ec76c39453ff267c6ba19c0605eb406b7/debian/patches/0002-write-pom-make-pom.properties-generated-date-reproducible.patch

clojure.zip/next may execute `make-node` up to 3 times

Fri, 14 Feb 2025 10:55:35 +0000

When I traverse a nested structure with a zipper, modify a node deep inside and want to get the whole updated structure back, each time I visit an ancestor node of the modified one, my make-node function is unnecessarily called 3 times by the clojure.zip/next function.

Reviewing the implementation of the next function, I see that storing the result of (up p) in a variable/binding would get me rid of the extra make-node calls (and I have tested that it does).

I identified this issue in a Clojurescript REPL but it looks like it's present in the Clojure implementation, too.

Do stream interop functions close the stream?

Sat, 08 Feb 2025 16:23:45 +0000

Docs for the handy new stream interop functions (stream-seq!, stream-into! etc) say they "are terminal stream operations (they consume the stream)."

Just to be totally clear, does this mean they close (.close) the streams?

I ask because I use these functions with the stream returned from java.nio.file.Files/list and when I'm benchmarking the app I sometimes get "too many open files" Java errors. I can't think where else I might conceivably be leaving a file handle open, beyond that I'm almost entirely just using slurp (for now at least).

(Naively, I would expect everything except stream-seq! to close out the stream by the time it returns, and stream-seq! I would expect to close once the seq is consumed and/or garbage collected)

Could we have a msg arg to time?

Wed, 22 Jan 2025 21:03:28 +0000

Very handy in CLJC projects especially to log long running operations. Happy to do PR(s).

  [expr msg]
  `(let [start# (. System (nanoTime))
         ret# ~expr]
     (prn (str msg (/ (double (- (. System (nanoTime)) start#)) 1000000.0) " msecs"))
     ret#))

Even better would be fmt-msg. (format msg-msg (/ (double (- (. System (nanoTime)) start#)) 1000000.0))

Incorrect docstring for parse-opts

Tue, 03 Dec 2024 16:02:27 +0000

In the docstring for clojure.tools.cli/parse-opts (seen here), it says,

:id           The key for this option in the resulting option map. This
              is normally set to the keywordized name of the long option
              without the leading dashes.

              Multiple option entries can share the same :id in order to
              transform a value in different ways, but only one of these
              option entries may contain a :default(-fn) entry.

              This option is mandatory.

The final line says "This option is mandatory." which is technically true for parse-opts' internals, but it's not true for users because (as the first paragraph says) :id is also generated by keywordizing the long option.

May I recommend changing it to be more explicit? Something like "If a long option is not provided, this option is mandatory."

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

Thu, 10 Oct 2024 14:34:39 +0000

Additional information on the EndElementEvent would be very helpful, especially for processing large data in a streaming way.

I would be happy to propose a patch – I've already signed the Contributor Agreement

No path in loop recur arg warning

Sat, 21 Sep 2024 13:12:31 +0000

Reflection warnings, such as for reflective method calls, are printed with the full source path (Compiler/SOURCE_PATH). This is different in case of the warning about loop recur args, printed with the source filename only (Compiler/SOURCE):

(set! *warn-on-reflection* true)

(defn reflective-method-call [] (.substring (try "") 0))

(defn boxed-recur-arg [] (loop [i 0] (recur (try i))))

...which prints:

Reflection warning, /home/pawel/dev/project/src/core.clj:22:33 - call to method substring can't be resolved (target class is unknown).
core.clj:24 recur arg for primitive local: i is not matching primitive, had: Object, needed: long
Auto-boxing loop arg: i

IMHO, the path is useful, especially if the filename is generic and inside a dependency.

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

Wed, 11 Sep 2024 20:16:33 +0000

Environment

clj --version
Clojure CLI version 1.12.0.1479

Source

A chat on Slack where we happened to notice the behaviour.

Scenario

When lib x is both a git dep and a maven dep,
clj -X:deps find-versions :lib x shows only versions from git deps.

Specific example: io.github.clojure/tools.build

As a git dep:

io.github.clojure/tools.build {:git/tag "v0.10.5" :git/sha "2a21b7a"}

As a Maven dep:

io.github.clojure/tools.build {:mvn/version "0.10.5"}

Reproduction

clj -X:deps find-versions :lib io.github.clojure/tools.build

Actual Behavior

Versions from git deps are listed:

{:git/tag "v0.9.4", :git/sha "76b78fe"}
{:git/tag "v0.9.5", :git/sha "24f2894"}
{:git/tag "v0.9.6", :git/sha "8e78bcc"}
{:git/tag "v0.10.0", :git/sha "3a2c484"}
{:git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:git/tag "v0.10.3", :git/sha "15ead66"}
{:git/tag "v0.10.4", :git/sha "31388ff"}
{:git/tag "v0.10.5", :git/sha "2a21b7a"}

Expected Behavior

TBD by Alex, but note that although maven deps exist, they are not listed.

A few ideas to poke at:

Idea One: populate this list with all available versions:

{:mvn/version "0.9.4" :git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5" :git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6" :git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0" :git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1" :git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3" git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4" :git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5" :git/tag "v0.10.5", :git/sha "2a21b7a"}

But maybe that's a bit confusing for users copy/paste-wise.

Idea Two: list all available versions side by side:

{:mvn/version "0.9.4"} {:git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5"} {:git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6"} {git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0"} {:git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1"} {:git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3"} {git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4"} {:git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5"} {:git/tag "v0.10.5", :git/sha "2a21b7a"}

Idea Three: list all available versions sequentially

{:mvn/version "0.9.4"} 
{:mvn/version "0.9.5"} 
{:mvn/version "0.9.6"} 
{:mvn/version "0.10.0"}
{:mvn/version "0.10.1"}
{:mvn/version "0.10.3"}
{:mvn/version "0.10.4"} 
{:mvn/version "0.10.5"} 
{:mvn/version "0.9.4" :git/tag "v0.9.4", :git/sha "76b78fe"}
{:mvn/version "0.9.5" :git/tag "v0.9.5", :git/sha "24f2894"}
{:mvn/version "0.9.6" :git/tag "v0.9.6", :git/sha "8e78bcc"}
{:mvn/version "0.10.0" :git/tag "v0.10.0", :git/sha "3a2c484"}
{:mvn/version "0.10.1" :git/tag "v0.10.1", :git/sha "5e3b8f3"}
{:mvn/version "0.10.3" git/tag "v0.10.3", :git/sha "15ead66"}
{:mvn/version "0.10.4" :git/tag "v0.10.4", :git/sha "31388ff"}
{:mvn/version "0.10.5" :git/tag "v0.10.5", :git/sha "2a21b7a"}

Could clojure.java.process support more convenient interactive usage?

Fri, 30 Aug 2024 14:20:57 +0000

I've been using clojure.java.process from the Clojure 1.12 RCs a lot and it's great having that functionality built right in to clojure.

I frequently find myself wanting a fully interactive process that blocks until exit. For example

(require '[clojure.java.process :as p])
(let [p (p/start
            {:in  :inherit
             :out :inherit
             :err :inherit}
            "bash")]
    @(p/exit-ref p))

Having your repl become a bash shell is an extreme (but often useful) example. More frequently you might want to just call a script that has a yes or no prompt. During development and repl usage it's also a convenient default, in cases you hit some user input prompt you didn't expect and can now just answer in the repl.

Could it be worth it to add some means to support this to the clojure.java.process namespace?

Java's ProcessBuilder has inheritIO.
babashka.process has the ability to set :inherit to true to set all io options as well as the shell function.

Of course this I could easily use my own helper function for this or just use babashka.process instead. But I am contending that having such usage conveniently supported out of the box perhaps might get a lot of "bang for the buck".

A counterpoint is that this is one of numerous things that could be added to that namespace. There are tons of ways people might want to work with processes and clearly clojure.java.process shouldn't try to maximize convenience for every single one of them.

Separate bindable reporting function from clojure.test/report

Tue, 27 Aug 2024 18:38:20 +0000

Set Up

clojure.test is built on the idea that a test will call an assertion function that directly calls a reporting function: is calls report (through do-report). The function report is a multimethod, allowing for adding or overriding keys to allow for implementing alternative reporting styles. It's also dynamic, meant to be rebound if an entirely new reporting system is to be used (TAP, JUnit, etc).

Problem

As discussed in the excellent kaocha source code, these two approaches don't work together, which leads to issues such as kaocha's workarounds (and monkey-patching), leiningen's monkey-patching, Cursive's test runner not always integrating with other tools due to binding report, and others.

Alessandra Sierra wrote about this issue as well when she attempted a follow-up to clojure.test called Lazytest (which I have resurrected over the last year). She ended up not finishing the library, and many other alternatives to Clojure test have not been as successful as one might hope either.

Given that clojure.test is here to stay, it seems prudent to make it easier to use and adapt without changing the fundamental api.

Potential Solution

Separating the "dynamic variable to be rebound" from "the default reporting function" would make it easier for libraries and tools to choose to extend report or replace it entirely, without worrying that they'll clash or run into each other. This can be accomplished by adding a new dynamic variable *reporter* to clojure.test that do-report calls, and defaulting *reporter* to clojure.test/report. (report would stay dynamic so as to not change working code.)

With such a change in place, workarounds such as Leiningen's monkey-patching could simply bind *report* with a new function and not worry about stepping on any other library's toes.

Comparison ops "Return non-nil if..., otherwise false"

Wed, 31 Jul 2024 01:41:56 +0000

The docstring of < (and others) says:

Returns non-nil if nums are in monotonically decreasing order,
otherwise false.

That seems a bit weird since a) they return either true or false and b) false is "non-nil" so it seems misleading / unhelpful.

What is the history for saying "non-nil" rather than true?

Missing documentation for `:while` modifier of `for` and `doseq`

Mon, 01 Jul 2024 13:56:08 +0000

I believe the for and doseq documentation (at least docstrings) fail to explain the semantics of the :while modifier. The existence is documented, but not the behavior.

I would like to request that the doctoring be updated, especially since it behaves in what I believe is a reasonable but counter-intuitive way. I believe a reasonable person would expect that :while false would trigger the for or doseq to exit; however it does not. Rather it causes the inner-most loop containing the :while to exit, but most notably the outer loops continue to iterate.

Another discussion of this can be found here: clojurians

Expand FI adapting to SAM types (not marked as FI)

Fri, 24 May 2024 12:50:20 +0000

There are a lot of SAM types that are not FI in the JDK - some prominent ones are Executor, ThreadFactory, etc. Increasing the scope of what we adapt would allow us to be closer to Java’s support and would expand the scope of where this support can be used.

Simple example:

;; Adapt Thread constructor method value to ThreadFactory (not FI)
;; Use the factory to get a Thread with a Runnable and start it
(let [^java.util.concurrent.ThreadFactory tf ^[Runnable] Thread/new]
  (.start 
    (.newThread tf #(println "hi"))))

Execution error (ClassCastException) at user/eval145 (REPL:1).

class user$eval145$invoke__Thread_new__149 cannot be cast to class java.util.concurrent.ThreadFactory

Jira: https://clojure.atlassian.net/browse/CLJ-2856

Support Clojure 1.12-alpha12 Array class notation

Thu, 23 May 2024 19:02:29 +0000

Currently, the function clojure.tools.reader.impl.commons/parse-symbol is fairly lax with what it allows, both in general and with regard to the forthcoming Clojure 1.12 Array class notation.

user=> (mapv trc/parse-symbol ["String/1" "String/-1" "String/11" "String/1a"])
[nil ["String" "-1"] nil nil]

This is different than the current implementation, which only accepts the first. Is there any interest in updating it to be stricter for the new notation?

Could re-pattern be extended to allow flags?

Wed, 22 May 2024 17:02:15 +0000

The JVM method java.util.regex.Pattern has the option of taking a second parameter for flags, which is a bitwise combination of the various allowed values. Has a similar arity been considered for the clojure.core.re-pattern function?

For instance:

(def rflags {\i java.util.regex.Pattern/CASE_INSENSITIVE
             \m java.util.regex.Pattern/MULTILINE
             \s java.util.regex.Pattern/DOTALL
             \u java.util.regex.Pattern/UNICODE_CASE
             \d java.util.regex.Pattern/UNIX_LINES
             \x java.util.regex.Pattern/LITERAL
             \c java.util.regex.Pattern/CANON_EQ})
(defn re-flags [s] 
  (reduce bit-or 0 (map #(rflags % 0) s)))

(defn re-pattern
  "Returns an instance of java.util.regex.Pattern, for use, e.g. in
  re-matcher."
  {:tag java.util.regex.Pattern
   :added "1.0"
   :static true}
  ([s] (re-pattern s 0))
  ([s f] (if (instance? java.util.regex.Pattern s)
          s
          (. java.util.regex.Pattern (compile s f))))

Some notes on this:
- Most of these flags can already be added to a pattern today using a ? modifier. For instance, a pattern can be made case insensitive by adding (?i) to the start of the string. However, allowing a flags string is compatible with JavaScript (and could be implemented on ClojureScript)
- There are currently no options to define LITERAL or CANON_EQ without using java.util.regex.Pattern directly.
- There is currently no way to implement any flags in ClojureScript without using interop.
- While not all of these flags are compatible with JavaScript, the more common ones are. Similarly, JavaScript allows for flags that are not compatible with Java, so there is already a small disconnect.
- Passing 0 for the default flags is indeed what java.util.regex.Pattern(String) does.

Request: def should infer type tag where possible

Fri, 03 May 2024 20:01:21 +0000

Maybe there’s a good reason why it doesn’t, but it seems to me it would be great if def would automatically infer type hint:

(let [s "abc"]
  (.chars s)) ;; all fine, no warning

(def s "abc")

(.chars s) ;; Reflection warning, null:21:0 - reference to field chars can't be resolved.

(meta #'s) ;; ↓ notice -- no tag
;; {:line 19,
;;  :column 0,
;;  :file "NO_SOURCE_FILE",
;;  :name s,
;;  :ns #object[clojure.lang.Namespace 0x78068afb "user"]}

clojuredoc sort is wrong with respect to comparator

Fri, 19 Apr 2024 09:51:42 +0000

The clojuredoc for sort says:
comparator MUST implement java.util.Comparator.
However, this does not seem to be the case. The function provided as 1nd argument to 2-ary sort may return explicitly true or false; it need not implement java.util.Comparator.

It would be nice if the clojuredoc were updated to reflect this important feature.

There is another document https://clojure.org/guides/comparators which explains in greater detail. But the existence of that document does not obviate (in my opinion) the short doc from being correct even if incomplete.

Could clojure.core/slurp support sun.nio.fs.UnixPath as its argument?

Sun, 07 Apr 2024 13:27:34 +0000

Hi!

I use babashka.fs/glob a lot. It returns a sequence of matches, where each match is a sun.nio.fs.UnixPath. Example:

(require '[babashka.fs :as fs])
(fs/glob "." "*.edn")
;; => [#object[sun.nio.fs.UnixPath 0x7d586fe1 "deps.edn"]
;;     #object[sun.nio.fs.UnixPath 0x6b25665b "bb.edn"]]

I often want to read these files. I often try the following:

(->> (fs/glob "." "*.edn")
    (map slurp))

, before I remember that doesn't work, so I do this instead:

(->> (fs/glob "." "*.edn")
    (map fs/file)
    (map slurp))

. So I would think it would be nice if clojure.core/slurp could support an input argument of type sun.nio.fs.UnixPath.

Combining :exec-args from multiple aliases with user-defined semantics

Wed, 27 Mar 2024 12:32:27 +0000

I was looking for a way to invoke an nREPL server using clojure -X and specify extra dependencies and middleware in separate aliases which would be composed together on the command line.

For context: nREPL middleware are specified as a list of functions/runtime-resolved symbols, so ideally there would be some mechanism for each alias in the deps.edn to specify their own vector-of-middleware and have them concatenated in the order which the aliases were listed on the command line. (See below for concrete demonstration of this)

Unfortunately I couldn't find a satisfactory way of achieving this via the clojure CLI - the issue is that :exec-args maps from different aliases are simply merged, with latter values overriding earlier ones. The clojure.org reference mentions deep merging but this appears to be a doc error.

(Note that the widespread use of -M for this use case does not afford any way of composing command-line string args, forcing each alias to couple together all middleware and dependencies.)

Of course there shouldn't exist some magic set of semantics for merging exec-arg values (vectors => concat, maps => merge etc.)... Nevertheless there might be a usability gap to fill here, letting users specify their own merging semantics declaratively rather than having to resort to custom-coded task runners .

An example of how this would look like from the command line, given concat semantics for the :middleware arg:

$ clojure -X:nrepl
Starting nREPL server with: nil

$ clojure -X:nrepl :port 1234
Starting nREPL server with: {:port 1234}

$ clojure -X:cider:nrepl :port 5678
Starting nREPL server with: {:port 5678 :middleware [cider.nrepl/cider-middleware]}

$ clojure -X:portal:cider:nrepl
Starting nREPL server with: {:middleware [portal.nrepl/wrap-portal, cider.nrepl/cider-middleware]}

$ clojure -X:cider:cljr:portal:nrepl
Starting nREPL server with: {:middleware [cider.nrepl/cider-middleware, refactor-nrepl.middleware/wrap-refactor, portal.nrepl/wrap-portal]}

see this conversation in Slack thread for more context:
https://clojurians.slack.com/archives/C6QH853H8/p1711461045176759

Warn about user.clj during build compilation

Wed, 28 Feb 2024 13:20:46 +0000

We’ve had a few cases where people encountered issues due to the existence of user.clj during uberjar building with tools.build.

Because user loads early, anything it loads is not (typically) reloaded during compilation, which can lead to some namespaces not being compiled.

Should maybe warn if user is on classpath or even actively recompile with something like

(binding [*compile-files* true] (require 'user :reload-all))

Option in `clojure` CLI command to print the basis

Thu, 15 Feb 2024 13:57:44 +0000

It would be nice that clojure could print the basis for a given combination of aliases (or none).

A common use case is obtaining the computed :paths for a combination of aliases.

spec for extend-protocol

Wed, 14 Feb 2024 14:05:57 +0000

Many macros in clojure have a spec which get executed by the compiler at macro-expansion time.

At this time extend-protocol doesn't have such a spec.
I'd like to know if extend-protocol is supposed to work with (Class/forName ..) or that the class name to which the protocol is extended must always be a symbol. A spec would be the natural place to get this answer from. extend-protocol is known to not work with Class/forName when you provide more than one:

(extend-protocol IFoo (Class/forName "[B") (Class/forName "[D")) Syntax error (IllegalArgumentException) compiling at (REPL:1:1). Don't know how to create ISeq from: java.lang.Character

If the spec says anything about this, I can also make linting for this in clj-kondo. At this time it seems to be ambiguous: (extend-protocol IFoo (Class/forName "[B")) does work.

Does `:exclude` need to be added to https://clojuredocs.org/clojure.core/require ?

Tue, 13 Feb 2024 19:29:06 +0000

https://clojuredocs.org/clojure.core/require makes no mention of :exclude but this seems to work as it appears:

(require '[clojure.set :refer :all :exclude [join rename]])

Support for js/BigInt

Fri, 09 Feb 2024 13:32:21 +0000

Native support for BigInt in JavaScript has been around since 2020. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt)

Any chance of support for this in ClojureScript any time soon?

Would be nice to be able to use this as a number in numeric ops and as a key in hash maps.
Also, cljs.core could be extended with functions like bigint and integer? from clojure.core.

BigInts would bring clojurescript one step closer to supporting Ratios.

`resolve` should support array class symbols?

Fri, 09 Feb 2024 02:06:42 +0000

Clojure 1.12.0-alpha6 has introduced array class symbols, but it doesn't seem that resolve supports them right now:

(resolve 'long**) ;=> nil
(resolve 'String**) ;=> nil

It would be nice if resolve would be aware of array class symbols. Otherwise, it'd require extra work for some sorts of macros and development tools (that use resolve under the hood) to support them.

Dedupe doesn't mention statefullness in docstring

Mon, 22 Jan 2024 12:22:44 +0000

Unlike all other core functions which can return a stateful transducer, dedupe doesn't mention this in its docstring. E.g. distinct, drop-while etc. all say:

Returns a stateful transducer when no collection is provided.

But dedupe just says:

Returns a transducer when no collection is provided.

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

Tue, 16 Jan 2024 22:14:09 +0000

For comparisons (= < <= > >= ==) arity 3 and higher are much slower than doing e.g. (and (< a b) (< b c)). The arity 3 is in my research rather less common but still used in e.g. Manifold stream.clj [0] or rrb_vector rrbt.clj [1]. Arity 3 is idiomatic in places, where you compare lower and upper bound for a "variable". However, I don't think arity 4 and higher is used much in practical code. At least I haven't found any interesting instances of such a use.

An example implementation (based on the one currently in core) could be:

(defn <'
  "Returns non-nil if nums are in monotonically increasing order,
  otherwise false."
  {:inline         (fn [x y] `(. clojure.lang.Numbers (lt ~x ~y)))
   :inline-arities #{2}
   :added          "1.0"}
  ([x] true)
  ([x y] (. clojure.lang.Numbers (lt x y)))
  ([x y z] (and (<' x y) (<' y z)))
  ([x y z & more]
   (if (<' x y z)
     (if (next more)
       (recur y z (first more) (next more))
       (<' z (first more)))
     false)))

[0] https://github.com/clj-commons/manifold/blob/c3fc69066f3abba0b5ab0f4c2b1c4338bcc61d19/src/manifold/stream.clj#L978
[1] https://github.com/clojure/core.rrb-vector/blob/master/src/main/clojure/clojure/core/rrb_vector/rrbt.clj

Can't know if value in option map is default or user-supplied

Wed, 13 Dec 2023 14:28:17 +0000

I have a program that accepts a number of options at the CLI that I allow to be specified in a config file as well. That way, instead of passing --quiet to all calls, one can put into .splint.edn the map {quiet true} to have it enabled automatically. It is valuable sometimes to override the config file by passing the option at the CLI so when building the options map, I first load the config file and then merge in the CLI options: (merge local-config cli-options)

However, if I specify a default in the tools.cli spec, I lose that behavior because the defaulted option will unconditionally overwrite the config file when merged as it is always present in the CLI options map.

I've taken to leaving out the :default key from my tools.cli specs, opting to just write "Defaults to true." in the option description string. For example, [nil "--[no-]parallel" "Run splint in parallel. Defaults to true."] and then later (get config :parallel true) and then later (merge local-config cli-options). This means my summary doesn't have the pretty-printed FALSE in the option. (For example, --[no]-parallel FALSE Run splint in parallel.)

I've a few ideas about how to solve this little snag for me (beyond "You've already solved it, do nothing!"):
1) return an additional key from cli/parse-opts, something like :defaults. It would be a seq or set of the options that used the defaults. That way, I can add some logic like (merge (select-keys cli-options defaults) local-config (apply dissoc cli-options defaults)).
2) Add a :default-display to the cli/parse-opts specs, which will print the default without adding it to the options map. It would be on the user (dev) to ensure it's actually added to the options map or used in some way.
3) Add some functionality that allows for specifying a default in the summary but puts something else in the map. For example, --[no]-parallel FALSE but the map gets {:parallel :false}. This would let me choose the right value as appropriate.

Thanks so much!

data.xml : disable support-dtd by default

Mon, 04 Dec 2023 19:14:34 +0000

As defined by OWASP recommendations [1], both supporting-external-entities and support-dtd should be disabled by default.
While it's the case for the former (but not released as part of the 0.0.8 version), it's not the case for the latter.

Can we consider having both defined to false as part of a stable version?

[1] : https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#xmlinputfactory-a-stax-parser.

Add support for context logging in tools.logging

Sun, 26 Nov 2023 16:21:19 +0000

Structured logging beats plain text.
Context logging + structured logging is a net win. At my workplace we could dump our ad-hoc logging solution which besides support for context logging is inferior to tools.logging, and will make a strong addition to the library's capabilities.
To add support for context logging, we'll probably need an additional protocol for the frameworks which implement such APIs (like SLF4J).
Not sure if it's required, but an additional logging function might also simplify the implementation.
Suggested usage:

(log/info-c {:foo "bar"} my-error "some message")

Is tools.build considering adding a :license argument?

Fri, 29 Sep 2023 17:17:01 +0000

Now that Clojars requires licenses, projects that need to go up there need a license block in the pom files of their jars. Using build.tools it's possible to create a pom.xml, manually edit it to include a license section, then create a jar using that pom. But, that's manual.

Are there plans to add an option for write-pom (and gen-pom) to allow programmatic insertion of a license?

Why doesn't clojure.set provide a "symmetric difference" function?

Mon, 25 Sep 2023 20:44:24 +0000

Is there a particular reason why clojure.set does not provide a symmetric-difference function?

It seems a relatively frequent thing to want.

Support of Maven Password Encryption in tools.deps

Mon, 25 Sep 2023 12:09:30 +0000

Hello,

When I try to use Maven Password Encryption, dependency resolution fails with 401 HTTP error code because tools.deps sends encrypted password from settings.xml without decryption. I used the following scenario:
1. Create settings.xml and settings-security.xml with encrypted master and server passwords according to the Maven guide.
2. Add the repository from settings.xml to deps.edn according to Maven authenticated repos guide
3. Ensure that ~/.m2/repository doesn't have some Maven dependency from deps.edn
4. Create pom.xml with the same list of dependencies as those that are in deps.edn
5. Run clj -X:deps tree. The command fails with 401 HTTP error code
6. Run mvn dependency:tree. The command resolves and downloads all dependencies
7. Remove some dependencies from ~/.m2/repository
8. In settings.xml replace encoded server password by plain text server password
9. Run clj -X:deps tree. The command resolves and downloads all dependencies

I've looked to sources of tools.deps and it looks like there is no support of such passwords, but it can be the case that I was looking in wrong places.

Could you please help me to understand - am I using incorrect configuration in deps.edn, or tools.deps doesn't support encrypted Maven passwords?

Missing stateful string accumulator function (for transduce target)

Fri, 15 Sep 2023 19:04:56 +0000

If you have a transducer chain that makes a stream of strings, you might want to accumulate them at the end into a string. Existing functions like str will generate a lot of overhead as there is no stateful accumulator you can maintain.

What you really want is a StringBuilder that accumulates, and emits the string at finalization.

String joining could then be something like:

(transduce (interpose ",") str! coll)

extensible with more transducers as needed.

cgrand's xforms lib has something like this: https://github.com/cgrand/xforms/blob/2079b74271b858b6a91dcb87bc58f3b93ea0b19c/src/net/cgrand/xforms/rfs.cljc#L145-L147