Clojure Q&A - Recent questions tagged metadata

`eval` using functions with metadata

Mon, 01 Jun 2026 14:33:00 +0000

TIL:

(eval (list + 1 2)) ; works
(eval (list (var-get #'+) 1 2)) ; works
(eval (list (fn [a b] (+ a b)) 1 2)) ; works

(defmacro m [] `(~(fn [a b] (+ a b)) 1 2))
(m) ; also works

;; however, if the function has any metadata:
(eval (list (with-meta + {}) 1 2))
;; ^ fails, No matching ctor found for class clojure.lang.AFunction$1

This was unintuitive to discover.

I solved it locally with a little helper:

(defn val->expr [v]
  (if (symbol? v)
    `'~v
    (cond-> v
      (and (fn? v) (not (nil? (meta v))))
      (-> (with-meta nil)
          (list (-> v meta (update-vals val->expr)))
          (conj `with-meta)))))

But this takes special handling. I wonder if something similar would not be possible on a "matching ctor"-level, possibly also for comp, every-pred?, etc. It would be fairly trivial even in userland to have versions of these functions which carry metadata sufficient to recreate expressions, e.g. comp storing the list of functions, and then eval, on encountering No matching ctor found for class clojure.core$comp$fn__5921, can instead pull out the list of functions from that value and evaluate (list* comp (:composed-fns (meta v))) (or some such) instead.

I think this would be great to have in the core lib, at least for metadata and core libs functions like comp, some-fn, every-pred?, and complement.

Note, I'm not talking about adding or changing ctors for these necessarily. A hook for taking unconstructable values and making a constructable value out of them would serve just as well, maybe even a multifn.

Strictly in userland and without core lib support, I suppose the cleanest way to do something like this is a custom protocol and probably monkeypatch some core libs functions (maybe eval?)

So I suppose my questions are:

Is this something you agree would be good to have in general? Or is this by design for some reason I can't see?
Would this be good and practical to have in the corelib? Oughtn't be a breaking change at least
If no, is there currently any sane way to apply my solution in a more systemic way than wrapping every relevant value with a val->expr call?

Is it valid for metadata to have metadata?

Thu, 12 Feb 2026 15:45:20 +0000

Hello,

I am implementing a pretty printer and while adding/testing support for *print-meta* I noticed that pr prints an object whose metadata has metadata in the following way:

user> (binding [*print-meta* true]
        (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork}))))
"^^{:frob :zork} {:bar :baz} foo"

When reading such a form, only the "outermost" metadata is preserved:

user> (binding [*print-meta* true]
        (let [s (pr-str (with-meta 'foo (with-meta {:bar :baz} {:frob :zork})))
              o (clojure.edn/read-string s)]
          {:o o
           :meta (meta o)
           :metameta (meta (meta o))}))
{:o foo, :meta {:bar :baz}, :metameta nil}

The behaviour is the same for clojure.core/read-string and also the tools.reader readers.

Can anyone clarify for me if this is either:

simply GIGO
a bug in the printer
a bug in the readers
a state that should be somehow disallowed
something else?

Neither the metadata reference nor the reader reference explicitly allow or disallow such a thing, as far as I can tell. Should they?

N.B. this is not an issue in any kind of production context and I'm not aware of any library or program that constructs such a thing. It's simply something I tested to see if/how it would break the pretty printer I'm building.

EDIT:

I dug into this some more with Nicola. Here's a perhaps much clearer case that demonstrates the reader isn't propagating nested metadata:

user> (let [o ^^:foo {1 2} {3 4}]
        {:o o :meta (meta o) :metameta (meta (meta o))})
{:o {3 4}, :meta {1 2}, :metameta nil}

:metameta should be {:foo true}.

In this section of MetaReader.invoke we are iterating over the entries of the meta map and manually associng them into the existing meta of the object; any metadata on the meta map itself is not preserved. I have a patch that adds a failing test case and correctly propagates the the meta map's metadata. If this is worth a ticket then I'm more than happy to attach it to that or send it to you directly.

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.

what does ^:once meta applied for anon function mean?

Sun, 02 Jul 2023 13:07:57 +0000

hi!
what does ^:once meta applied for anon function mean?

(db-query-with-resultset* db sql params
                           (^:once fn* [rset]
                             (process-result-set rset opts))
                          opts)

Thanks

Are there plans for official docs (rationale and guide) on datafy / nav?

Sat, 11 Sep 2021 10:26:57 +0000

If Clojure is to become (even) more data oriented, these are powerful tools to achieve that goal. The community needs support to encourage adoption.

The current state of documentation for datafy and nav is not sufficient IMHO to encourage independent learning on a broad scale.

There is no canonical source of such documentation in the community despite some valiant efforts (eg @SeanCorfield who has a great blog post and is an active proponent).

Examples are difficult to find around the internet ... here's a good one from a Slack recommendation by @Frederick on there.

We know that there are problems with Slack since we cannot easily search history so keeping it here might help people find it in the meantime.

It would be good to have a rationale explaining the problem it is solving, the general approach and some specifics on the design.

Likewise a guide on how it should be used with a worked example and some hints and tips on how to approach implementations.

I know it's marked as alpha but this has not prevented docs on other aspects of the language.

which two objects share the same sequence?

Fri, 09 Jul 2021 11:17:12 +0000

The documentation for metadata https://clojure.org/reference/metadata contains a confusing sentence which I think it grammatically incorrect.

The sentence is: One consequence of this is that applying metadata to a lazy sequence will realize the head of the sequence so that both objects can share the same sequence.

Can someone please explain grammatically correctly what the 2nd sentence in the 3rd paragraph means?

What are the two objects (both) in question and which sequence is shared between these two objects?

Since the sentence is ambiguous, I'm not 100% sure what it means. But here is my attempt to correct the sentence. Please feel free to correct my incorrect-correction.

That said, metadata and its relationship to an object, A, is immutable - an object, B, with different metadata is a different object. One consequence of this is that applying metadata to A (if A is a lazy sequence) will realize the head of the sequence so that objects A and B can share the same meta-data.

Additional discussions can be found here https://clojurians.slack.com/archives/C03S1KBA2/p1625827141061700

Is tag metadata that represents function calls useful?

Tue, 22 Jun 2021 10:08:17 +0000

The following is valid Clojure (focus on extend-type (class (log-window-proxy nil)), as opposed to refering to a class literal):

(defn- log-window-proxy [state]
  (proxy [javax.swing.JTextArea clojure.lang.IDeref] []
    (deref [] state)
    (scrollRectToVisible [rect]
      (if @(:auto-scroll? state)
        (proxy-super scrollRectToVisible rect)))))

(defprotocol LogWindow
  (log   [this message])
  (clear [this]))

(extend-type (class (log-window-proxy nil))
  LogWindow
  (log [this message]
    (println "message" message))
  (clear [this]
    nil))

However, when one inspects the :tag metadata that this is given, it appears to have an somewhat odd form (since it remains a chain of calls, instead of a class literal):

(-> (extend-type (class (log-window-proxy nil))
      LogWindow
      (log [this message]
        (println "message" message))
      (clear [this]
        nil)) quote macroexpand last :log second ffirst meta)
;; => {:tag (class (log-window-proxy nil))}

So, the :tag looks like a function call. Will the compiler end up invoking (class (log-window-proxy ... to obtain a class that it can actually use as a type hint?

Otherwise I'd be worried that this :tag metadata was invalid, which might cause reflection warnings and additionally confuse arbitrary third-party tooling.

Bind ns and require before evaluating namespace metadata

Tue, 05 Jan 2021 20:15:04 +0000

Before evaluating its namespace metadata, I wish ns macro would:

Have *ns* be bound already.
:require, to be able to use :as namespace names in metadata expression.
Example:

Current (uses fully qualified names):

    (ns my.app.foo.controller
      {:tape.mvc/interceptors [(re-frame.core/path
                                [:my.app.foo.controller/controller])]}
      (:require [re-frame.core :as rf]
                [tape.mvc :as mvc]))

After change (uses "shortcut" names):

    (ns my.app.foo.controller
      {::mvc/interceptors [(rf/path [::controller])]}
      (:require [re-frame.core :as rf]
                [tape.mvc :as mvc]))

Would this change be worthwile/acceptable/feasible?

Function with meta equality fails

Wed, 23 Dec 2020 16:08:44 +0000

Bug report:

(defn f [] 1)
=> #'cljs.user/f
(= f (with-meta f {:a 1}))
=> false ;; should be true

Per: https://clojure.org/reference/metadata
"metadata does not impact equality"

How could I add metadata to specs?

Sun, 05 Jul 2020 02:10:12 +0000

I'm trying to implement traceability into my specs.
(With "specs" I specifically mean s/def and s/fdef blocks.)

Originally, I came up with the idea to use metadata for this. However, that's unfortunately not possible: the code below gives me a syntax error... (Metadata can only be applied to IMetas.)

(require
    '[clojure.spec.alpha :as s])
(s/def
      ^{:rule "205.3i"
        :version "2020.06.01"}
      ::basic-land-type #{::forest ::island ::mountain ::plains ::swamp})

The only other way I can think of is to somehow attach the metadata as a "guardian" element within the file (let's say, a def)

However, it seems quite ugly...

(def
  ^{:rule "205.3i"
    :version "2020.06.01"}
  tracing-info "(see metadata)")

Would anyone know some way I could use to achieve this?

Why can't anonymous functions access their metadata unless they were created with some

Sat, 26 Oct 2019 15:30:47 +0000

These two expressions have a different result:

((with-meta
   ^:any (fn self []
           (meta self))
   {:foo :bar}))

((with-meta
   (fn self []
           (meta self))
   {:foo :bar}))

The former returns {:foo :bar} the latter returns nil.

I'm guessing this is a bug, perhaps an unexpected consequence of an optimization?

(Filed: https://clojure.atlassian.net/browse/CLJ-2539)