Clojure Q&A - Recent questions tagged eval

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

Evaluating forms using eval can create a valid undesirable recursion point

Mon, 16 Mar 2026 23:17:54 +0000

When the eval function in Clojure is called with an argument that is an instance of IPersistentCollection which likely isn't a special def-like form (the first element isn't a symbol at all or it does not start with "def"), the form is first wrapped in an anonymous function which then gets compiled and invoked, which indirectly evaluates the original form.

There aren't any extra checks performed and it makes forms like these 2 valid, which should normally be rejected and a compiler exception should be thrown:

(recur)

(let []
  (print "Hello")
  (Thread/sleep 1000)
  (recur))

where the 2nd form keeps printing "Hello" and loops infinitely over the outer wrapper function.

How can I make Calva use a relative path when loading a file in cljs?

Mon, 23 Sep 2024 18:35:32 +0000

Is there a way to make Calva: Load/Evaluate Current File and its Requires/Dependencies use a relative path for ClojureScript instead of an absolute path?

I'm connecting to a docker container repl for development and the app is running at /app inside the container. Loading the current file in Clojure works as expected and evaluating things that have already been loaded in ClojureScript works as expected. Loading the current file in ClojureScript fails because it uses the host machine's full path. I get the following error:

; ------ REPL Error while processing ---------------------------------------------
; (cljs.core/load-file "/home/bmaddy/.../model/user.cljc")
; FileNotFoundException: /home/bmaddy/.../model/user.cljc (No such file or directory)

The following all work in the cljs repl as expected:

;; absolute path inside the container
(cljs.core/load-file "/app/src/.../model/user.cljc")
[]
;; relative path from project folder
(cljs.core/load-file "./src/.../model/user.cljc")
[]
(cljs.core/load-file "src/.../model/user.cljc")
[]

I see there are JACK_IN_PROJECT_ROOT_PATH and calva.replConnectSequences.projectRootPath settings, but they don't seem to affect this.

Some version info:
Calva version used: v2.0.474
clojure-lsp version used: 2024.08.05-18.16.00
VSCode Version: 1.93.1
OS: Linux

cljs.js/eval: def not working when using :simple optimization (works with :none/:whitespace)

Wed, 28 Dec 2022 15:51:59 +0000

as the title suggests, def appears to pass through without doing anything.

i.e. "(def x)" succeeds
but "(def x 10)" fails because
"Cannot read properties of undefined (reading 'x')"

article here: https://clojurescript.org/guides/self-hosting

suggests :simple optimization should work

to reproduce: https://github.com/sstraust/ClojureDefRepro (see comments for instructions)

Calva: Is there a way to evaluate a whole file?

Tue, 17 May 2022 14:33:43 +0000

Beside selecting the whole file and then evaluating the selection, can I evaluate the whole file in a more convenient way?

Adapted from questions asked in the #calva channel at Clojurians Slack.

Why does evaluating an eduction cause the reader to fail?

Tue, 11 May 2021 01:37:14 +0000

Providing an eduction to the repl will print the result in list format:

=> (eduction (map identity) [#'+ 2 3]) (#'clojure.core/+ 2 3)

This should not eval to 5, because an eduction is not a seq. However, when I try, then I expect to get the eduction returned, but instead I get an unexpected error from the reader in the REPL:

=> (eval (eduction (map identity) [#'+ 2 3])) Execution error (IllegalArgumentException) at user$eval183/<clinit> (REPL:1). No matching ctor found for class clojure.core$map$fn__5880

The stack trace for this seems to show that the error occurs in the reader:
`
java.lang.ExceptionInInitializerError

at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at clojure.lang.Compiler$ObjExpr.eval(Compiler.java:5000)
at clojure.lang.Compiler.eval(Compiler.java:7180)
at clojure.lang.Compiler.eval(Compiler.java:7136)
at clojure.core$eval.invokeStatic(core.clj:3202)
at clojure.core$eval.invoke(core.clj:3198)
at user$eval181.invokeStatic(NO_SOURCE_FILE:1)
at user$eval181.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:7181)
at clojure.lang.Compiler.eval(Compiler.java:7136)
at clojure.core$eval.invokeStatic(core.clj:3202)
at clojure.core$eval.invoke(core.clj:3198)
at clojure.main$repl$read_eval_print__9110$fn__9113.invoke(main.clj:437)
at clojure.main$repl$read_eval_print__9110.invoke(main.clj:437)
at clojure.main$repl$fn__9119.invoke(main.clj:458)
at clojure.main$repl.invokeStatic(main.clj:458)
at clojure.main$repl_opt.invokeStatic(main.clj:522)
at clojure.main$main.invokeStatic(main.clj:667)
at clojure.main$main.doInvoke(main.clj:616)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.main.main(main.java:40)

Caused by: java.lang.IllegalArgumentException: No matching ctor found for class clojure.core$map$fn__5880

at clojure.lang.Reflector.invokeConstructor(Reflector.java:288)
at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1317)
at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:853)
at clojure.lang.LispReader.read(LispReader.java:285)
at clojure.lang.LispReader.read(LispReader.java:216)
at clojure.lang.LispReader.read(LispReader.java:205)
at clojure.lang.RT.readString(RT.java:1879)
at clojure.lang.RT.readString(RT.java:1874)
at user$eval183.<clinit>(NO_SOURCE_FILE:1)
... 27 more

The source code at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1317) suggests that it's processing a list form where the first element ends with a dot character. This is unexpected

Namespace.java: addAlias exception could be more informative

Thu, 10 Oct 2019 15:55:01 +0000

In https://github.com/clojure/clojure/blob/653b8465845a78ef7543e0a250078eea2d56b659/src/jvm/clojure/lang/Namespace.java#L224-L225, the ns argument is not included in the exception message.

This hinders debuggabiliity, especially when the .addAlias call didn't originate from intentful aliasing, but rather, as a result of re-evaluating a namespace (which is the AST-building strategy that tools such as https://github.com/jonase/eastwood use).

Have you considered improving the message?