Clojure Q&A - Recent questions tagged spec

How to force clojure.spec generator to skip a field

Thu, 15 Jan 2026 07:58:46 +0000

(gen/let [x (s/gen (s/keys :opt [::a]))
          y (s/gen (s/keys :opt [::a]) {::a ???})])

If x generates without ::a, I'd also like to generate y without ::a. I can't presently see a way to express that.

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

What is an ideomatic way to use spec for API input validation?

Tue, 05 Nov 2024 20:58:16 +0000

Hi,

I'm pretty new to Clojure and recently got interested in using spec. One use-case I'm interested in, is to use it for validation of API inputs. As far as I understood I have the following possibilities to correctly declare / use specs in that case:

Create specs with unqualified names and use plain keywords in API input. I guess that's prone to error as one can think of overlapping specs with different requirements (e. g. having IDs with different scheme in two entities).
Create specs with qualified names and also use qualified names in API input. That would work as expected but feels like unnecessary extra work on the client side as all clients now need to specify the namespace for all keys while its usually clear which entity is expected (e. g. API endpoint /customer-address is expecting a customer address but still all fields need to be namespaced in the input like :customer-address/street).
Create specs with qualified names but use :req-un instead of :req to specify required keys in specs. Works as expected unless someone tries to validate a map with qualified names (shouldn't usually happen in API requests but might occur within the application where namespaces might not be a bad idea).
Create specs with qualified names and lift all keywords in API inputs into the expected namespace. Would work as expected and has the benefit that namespaced keywords can be used in the application. Drawback is that every API input needs to be transformed before validation can happen.

So, my question is, what is the ideomatic way to validate API input with spec?
And maybe as a bonus question: why is spec using the global "database" for specs? It looks like a lot of problems/confusion arise from that design decision (e. g. name clashes / overrides) and it also doesn't look like a very "functional" way. To clarify, I'm also not an expert in functional programming, so would be great if someone could highlight the benefits that led to that decision.

Best
Ben

`(s/gen ratio?)` throws exceptions

Wed, 08 May 2024 07:44:49 +0000

(s/gen ratio?) is implemented as (gen/such-that ratio? gen/ratio)

The problem is that about 10% of the time gen/ratio returns a whole number, which fails the ratio? predicate. If that happens 10 times in a row, gen/such-that throws an exception.

With a large enough sample size, (s/gen ratio?) reliably fails:

(dorun (gen/sample (s/gen ratio?) 10000000))

Execution error (ExceptionInfo) at clojure.test.check.generators/fn (generators.cljc:435).
Couldn't satisfy such-that predicate after 10 tries.

A quick fix is to increase the max-tries param for such-that:

(dorun (gen/sample (gen/such-that ratio? gen/ratio 100) 10000000))

=> nil

I do however also find it odd that (s/gen ratio?) always generates Ratios, but gen/ratio generates a mixture of ratios and integers. So perhaps a better fix would be to update gen/ratio to not generate integers?

clojure spec vs plumatic schema

Wed, 17 Apr 2024 04:11:04 +0000

A colleague brought to my attention that Clojure Spec is still alpha and that Plumatic Schema might be a better way to do the same tipe of spec.

Do you folks have any advice?

Cheers!

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.

`(s/explain-data (s/coll-of any? :count 1) (range))` hangs

Fri, 02 Feb 2024 20:59:37 +0000

(s/explain-data (s/coll-of any? :count 1) (range)) hangs.

The coll-prob impl has these lines:

(cond
  ...
  (c/and count (not= count (bounded-count count x)))
  [{:path path :pred `(= ~count (c/count ~'%)) :val x :via via :in in}]
  ...)

So for all non-counted collections with number of items larger than count, this branch is never triggered.
Maybe it should use (bounded-count (inc count) x) instead?

spec 1 :count fails uninformatively

Fri, 02 Feb 2024 19:17:54 +0000

Using Spec 1, it looks like the count validation failure could be reported better - it's not clear what the actual count was

user=> (s/assert (s/coll-of any? :count 1)
            [])
Execution error - invalid arguments to user/eval148 at (REPL:1).
[] - failed: (= 1 (count %))

Should s/keys error on bad arg keys (not :req, :req-un, etc)?

Sat, 26 Aug 2023 00:25:55 +0000

An s/keys spec will silently do nothing if it is defined without any valid arg key ( :req, :req-un, :opt, :opt-un, :gen).

Using req-un instead of :req-un (symbol instead of keyword, perhaps accidentally):

user> (s/def ::foo (s/or :string string? :number number?))
:user/foo

user> (s/def ::foo-map-broken (s/keys req-un [::foo]))
:user/foo-map-broken

user> (s/conform ::foo-map-broken {:foo []})
{:foo []}

;;arg key can be anything
user> (s/def ::foo-map-broken2 (s/keys 42 [::foo]))
:user/foo-map-broken2

user> (s/conform ::foo-map-broken2 {:foo []})
{:foo []}

My two cents: I tend to think calls to s/keys should be validated more aggressively so this produces an error. The only argument I can think of in favor of the current behavior is that the args to s/keys are effectively a map and maps are usually not treated as closed in Clojure. But 1> args that result in nothing happening still seem worth erroring on and 2> the user does not actually pass a map and may not realize that the implementation turns their arg keys and arg values into a map.

(I came across this behavior when clj-kondo flagged a spec of mine as incorrect and I noticed a typo just like above where I had req-un instead of :req-un. I fixed :req-un to be a keyword and this uncovered bugs in the spec but it had been a few months since I touched the code so I wished I had discovered it sooner :--) )

Inconsistent results from s/valid? and s/explain when trying to spec list of values

Wed, 24 May 2023 14:41:51 +0000

When using spec-tools (metosin/spec-tools {:mvn/version "0.10.5"}) to spec a list of values, result spec produces inconsistent results when validated against in s/valid? and s/explain.

Minimal example:

(ns case
  (:require [spec-tools.data-spec :as ds]
            [clojure.spec.alpha :as s]))

(def invalid-data {:cards (list 66)})

(def valid-data {:cards [66]})

(def cards
  {:cards [int?]})

(defn do-stuff [data]
  (if (s/valid? (ds/spec ::sp cards) data)
    (println "Conforms to spec according to 'valid?'")
    (println "Does not conform to spec according to 'valid?'"))
  (if (s/explain-data (ds/spec ::sp cards) data)
    (println "Does not conform to spec according to 'explain-data'")
    (println "Conforms to spec according to 'explain-data'")))

(comment
  (do-stuff invalid-data)
  (do-stuff valid-data))

For some reason s/valid? and s/explain produce different result when a list is used, but same when a vector is used. When I tried to reproduce this issue with spec created directly with clojure.spec.alpha, everything was fine, so it seems the problem is with spec-tools. Nevertheless, it should produce same results in all validation functions, I guess

Macro-expansion hooks similar to clojure spec

Tue, 23 May 2023 14:18:10 +0000

clojure.spec.alpha currently holds a privileged position as a core library for Clojure core, being able to instrument macros as well as functions. Compiler.java relies on clojure.spec.alpha in this function, calling macroexpand-check specifically. This is a neat interaction and macroexpand-check is simple and obvious.

Other tools (such as Malli) can provide instrumentation for Clojure functions through alter-var-root (as seen in malli.instrument/-strument!), but they lack the ability to hook into macro-expansions.

It would be nice if Compiler.checkSpecs had some hook to allow for tools such as Malli to be used to instrument macros.

Full specs for clojure.core in core.specs.alpha

Fri, 14 Apr 2023 15:09:25 +0000

Right now, core.specs.alpha only has specs for some basic special forms and macros.

Can it be expanded to include all functions defined in clojure.core? Or, perhaps there can be another optional namespace that contains these specs? I imagine having these specs available for instrumentation could be really helpful for training new Clojure programmers and bug-catching.

clojure.alpha.spec/gen can't generate samples for schemas containing unregistered specs

Tue, 07 Mar 2023 15:35:25 +0000

The wiki explains that we could include a map of unqualified keys to specs

Additionally, you may include a map of unqualified keys to the specs or spec names that should be used for them:
[::a ::b {:c (s/spec int?)}]

But generators created for such specs fail trying to resolve the spec

(require '[clojure.alpha.spec :as s]) (require '[clojure.alpha.spec.gen :as gen]) (s/def ::a string?) (s/def ::b string?) (gen/generate (s/gen (s/schema [::a ::b {:c (s/spec int?)}])))

returns the following error
> Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1957$fn$G (protocols.clj:11).
No implementation of method: :gen* of protocol: #'clojure.alpha.spec.protocols/Spec found for class: clojure.lang.PersistentList

Why isn't a spec for :clojure.spec.alpha/problems?

Wed, 22 Feb 2023 12:55:46 +0000

I wrote a spec to represent a validation outcomes and for the invalid one I'm including the list of problems reported by s/explain-data.
I have something like this
(s/def ::invalid-item (s/keys :req [::path :clojure.spec.alpha/problems]))

But this leads to some generative tests to fail since there is no spec defined for clojure.spec.alpha/problems
> Execution error at clojure.alpha.spec/reg-resolve! (spec.clj:90).
Unable to resolve spec: :clojure.spec.alpha/problems

Although I can perhaps infer the spec and define it in my own namespace I was expecting the spec to exist, is this a fair assumption?
Is it a good practice to use :clojure.spec.alpha/problems in my own spec or should I translate it to my own spec?

`(s/merge X Y)` disables conformation for `:*-un` keys in X

Sat, 21 Jan 2023 22:21:34 +0000

When merging map specs with unqualified keys, only the last spec retains its conformation behavior:

(s/def ::int-or-string (s/or :int int? :str string?))
(s/def ::a ::int-or-string)
(s/def ::b ::int-or-string)
(s/def ::a-un (s/keys :opt-un [::a]))
(s/def ::b-un (s/keys :opt-un [::b]))
(s/def ::merge-un (s/merge ::a-un ::b-un))
(s/conform ::merge-un {:a 100 :b "foo"})
;;=> {:a 100, :b [:str "foo"]}

Compare the behavior with qualified keys:

(s/def ::a-qual (s/keys :opt [::a]))
(s/def ::b-qual (s/keys :opt [::b]))
(s/def ::merge-qual (s/merge ::a-qual ::b-qual))
(s/conform ::merge-qual {::a 100 ::b "foo"})
;;=> #:user{:a [:int 100], :b [:str "foo"]}

how clojure.spec.alpha validation correctness is reasoned about?

Wed, 14 Dec 2022 14:48:44 +0000

Hi!
I am exploring an implementation of clojure.spec.alpha and found out a rather "little" (according to my naive expectations) set of tests :)

Clojure spec defines a set of primitives being able to compose one with each other.
Another words Clojure spec defines a language to describe structure + its predicative properties.

Assuming that spec semantics is described informally in Rationale and Guide how do you reason about the correspondence between declared semantics and spec implementation?

I expected a huge set of tests covering basic scenarios and finite number of their compositions -- kinda induction base. And if induction base is true then other compositions are also ok.

how do you reason about verification of the clojure.spec.alpha validation implementation correctness?

UPD: narrowed the question context to validation aspect according to Alex Miller first answer.

Accessing :column, :line & :file meta data of a Spec

Mon, 12 Sep 2022 08:56:40 +0000

Hello,

is it possible to somehow get at the :column, :line and :file
information of where a Spec was defined?

I believe this information could be collected from (meta &form) in
the s/def macro but isn't stored anywhere right now.

I would be great to have this information available to support REPL
based tooling for features like "jump to definition".

Spec alias behavior

Mon, 11 Jul 2022 15:01:18 +0000

I'm using spec.alpha from Clojure 1.11.1.

(require '[clojure.spec.alpha :as s])

Add spec ::foo with three specs that represent ways to "alias" another spec (direct, s/spec, s/and).

(s/def ::foo int?)

(s/def ::bar      ::foo)
(s/def ::bar-spec (s/spec ::foo))
(s/def ::bar-and  (s/and ::foo))

Problems with documentation

Only ::bar-and spec preserves the information about aliasing.

(s/form ::bar)      ;=> clojure.core/int?
(s/form ::bar-spec) ;=> clojure.core/int?
(s/form ::bar-and)  ;=> (clojure.spec.alpha/and :user/foo)

I find that useful, e.g. it's trivial to "find usages" of the ::foo spec.

Problems with generator overriding

Add spec ::m which aggregates specs from above.

(s/def ::m (s/keys :req [::foo ::bar ::bar-spec ::bar-and]))

Overriding data generator for underlying ::foo spec doesn't work for ::bar-spec alias.

(gen/generate (s/gen ::bar      {::foo (fn [] (gen/return 0))})) ;=> 0
(gen/generate (s/gen ::bar-spec {::foo (fn [] (gen/return 0))})) ;=> -2
(gen/generate (s/gen ::bar-and  {::foo (fn [] (gen/return 0))})) ;=> 0

(gen/generate (s/gen ::m {::foo (fn [] (gen/return 0))}))
;=> #:user{:foo 0, :bar 0, :bar-spec 31, :bar-and 0}

Overriding generator for alias spec doesn't work in the case of direct alias ::bar.

(gen/generate (s/gen ::bar      {::bar      (fn [] (gen/return 0))})) ;=> -492158
(gen/generate (s/gen ::bar-spec {::bar-spec (fn [] (gen/return 0))})) ;=> 0
(gen/generate (s/gen ::bar-and  {::bar-and  (fn [] (gen/return 0))})) ;=> 0

(gen/generate (s/gen ::m
                     {::bar      (fn [] (gen/return 0))
                      ::bar-spec (fn [] (gen/return 0))
                      ::bar-and  (fn [] (gen/return 0))}))
;=> #:user{:foo 183249700, :bar -1, :bar-spec 0, :bar-and 0}

The only way to override the generator for ::bar is to override it for ::foo. But that also affects all aliases of ::foo, which is not always desirable.

I like the behavior of s/and the most but its definition is arguably the most confusing for other users, because it sounds like s/and should have multiple arguments.

What is the rationale for behavior of other two approaches?
Is that expected?
Is there any alternative way to define aliases?
Will this be changed in the future spec?

Has middle of sequence &rest destructuring been considered?

Mon, 20 Jun 2022 13:23:18 +0000

Currently, Clojure allows for destructuring patterns that contain &rest arguments:

user=> (let [[a b & c] (range 5)] [a b c])
[0 1 (2 3 4)]

Python allows for the same, but also for placing the so-called catch-all in the front and middle position as well (PEP description):

>>> a, *b, c = range(5)
>>> a
0
>>> c
4
>>> b
[1, 2, 3]

Has similar been considered for Clojure? Could look like this:

user=> (let [[a & b c] (range 5)] [a b c])
[0 (1 2 3) 4]

I feel like this would be doable with how the core functions destructure currently works, but it’s possible I don’t know some subtlety.

Add support for checking instrumented syms in clojure.spec.test.alpha

Tue, 26 Apr 2022 15:48:48 +0000

The API for clojure.spec.test.alpha doesn't currently support finding the list of instrumented syms. This is useful, for example, when you want to restore the previous state of instrumentation. The list of currently instrumented syms is stored internally in an atom, so it might be reasonable that these syms could be exposed to the caller. Currently, the only way AFAIK to poll this information is as a side-effect of calling stest/unstrument.

It would be great if there was a function like instrumented-syms which could be called to identify what has already been instrumented. :)

Common patterns for optional fields interact poorly with spec

Tue, 15 Feb 2022 21:48:34 +0000

I do lots of work with spec, and a frequent problem that I run into is in constructing a spec'ed object that is a map with optional fields.

A common pattern looks like this:

(assoc {::required-field :value}
       ::optional-field (when some-condition
                          :optional-value))

There is a significant issue with this pattern however: if ::optional-field is on a spec/keys :opt field that is non-nilable, then every object that excludes the optional field will be invalid according to that spec because it will have a nil value instead of omitting the key.

The alternative to this approach is to use something like cond-> as seen below:

(cond-> {::required-field :value}
  some-condition (assoc ::optional-field :optional-value))

This pattern is far from the only usage of cond->, but it appears fairly frequently. I see this pattern as detrimental because it requires the condition to be surfaced all the way at the top here, and there cannot be a way for some function used to produce :optional-value to abort via nil punning while still producing a valid value without requiring additional flow control and local bindings.

A more flexible solution to this problem uses if-some, but this solution is verbose and becomes unwieldy when multiple optional fields need to be included at once, as can be seen below.

(let [m {::required-field :value}
      m (if-some [v (produces-optional-value)]
          (assoc m ::optional-field v)
          m)
      m (if-some [v (produces-other-value)]
          (assoc m ::other-field v)
          m)]
  m)

One solution to this problem is the function assoc-some, which is like assoc, but when given a nil value it elides the key. This function is provided in medley, and sees some use.

The above unwieldy example would, with assoc-some, look like this:

(assoc-some {::required-field :value}
            ::optional-field (produces-optional-value)
            ::other-field (produces-other-value))

This is likely not the only solution to this problem, but I think it is a problem worth considering.

An example of another instance where the named solution wouldn't work, but that appears to follow more or less the same pattern is this code in farolero, which would be solved by a parallel function (that I have not yet found an implementation of in the wild besides my own) update-some which will update a key with a new value, and if that value is nil will remove the key.

Unresolvable symbol safe for spec def?

Thu, 03 Feb 2022 00:44:47 +0000

I am able to register a spec with an unresolvable symbol even though the docs seem to indicate this should not be an acceptable value for the registry. Is this safe? Will it keep working?

The documentation for s/def says it takes as its first argument "a namespace-qualified keyword or resolvable symbol." This is more expansive than the spec Guide, which says, "Spec names are always fully-qualified keywords."

But I recently switched a bunch of specs from keywords to symbols (fully qualified but unbound) and everything seems to work fine, from s/valid? to s/conform to s/assert, referencing the definitions in s/keys, etc.

Here is a reduced example:

user> (require '[clojure.spec.alpha :as s])
nil
user> (ns-resolve 'com.example 'foo)
Execution error at user/eval30383 (form-init8866507034262802929.clj:53).
No namespace: com.example found
user> (s/def com.example/foo string?)
com.example/foo
user> (s/valid? 'com.example/foo "x")
true
user> (s/valid? 'com.example/foo 42)
false
user> (s/valid? (s/keys :req ['com.example/foo]) {'com.example/foo "x"})
true
user> (ns-resolve 'com.example 'foo)
Execution error at user/eval30389 (form-init8866507034262802929.clj:62).
No namespace: com.example found
user>

I am guessing this is an instance where the implementation has raced a bit ahead of the docs, and even further ahead of the guide. Either or that or maybe I'm misunderstanding what "resolvable symbol" means. Thanks for any guidance or tips!

The specs for `defn` do not roundtrip using `conform` / `unform`

Wed, 03 Nov 2021 15:11:03 +0000

There are patches and userland fixes in this JIRA ticket.

I am registering it here to enable upvoting!!

Does fdef support multimethods?

Fri, 24 Sep 2021 20:09:27 +0000

Hello, As of 2016 spec fdef did not support multimethods. Has this officially changed?

Although it seemed to work at first -- I was able to instrument and test a multimethod with fdef -- I later hit an issue using get-method on said multimethod after I instrumented it.

I could make a test case for the get-method instrumentation issue,but I thought I'd first clear up if this multimethod fdef usage is even supposed to work :-)

Spec `form` on `keys` missing namespace for `or`

Thu, 23 Sep 2021 11:31:47 +0000

[org.clojure/clojure "1.11.0-alpha2"]
clojure.spec.alpha

Repro (see or inside keys):

(s/def :x/foo int?)
(s/def :x/bar string?)

(s/form (s/keys :req-un [(or :x/foo :x/bar)]))
; => (clojure.spec.alpha/keys :req-un [(or :x/foo :x/bar)])

(s/form (s/and (s/keys :req-un [(or :x/foo :x/bar)])))
;=> (clojure.spec.alpha/and (clojure.spec.alpha/keys :req-un [(clojure.core/or :x/foo :x/bar)]))

Is there a way to force or to be namespaced in the first form?

Spec2: Use case for multi-spec as Schema provider

Tue, 15 Jun 2021 21:18:25 +0000

I have a scenario where I'd like to define some attributes that are internal and common, and some other attributes that are external and dynamic, both related to the same "things". Specifically, I am trying to model a trading library. There are many different exchanges/brokers/services, but all of them talk about similar/equivalent things.
Let's take the example of an order, you can have some attributes that can be common in all services (they don't necessarily appear on all services):

(spec/def :order/id string?)
(spec/def :order/quantity number?)
(spec/def :order/side #{:buy :sell})

Then, every external service can have specific attributes related to how that service handles orders:

(spec/def :service1-order/execution-instructions (spec/coll-of string?))
(spec/def :service2-order/iceberg-quantity (spec/coll-of string?))

I was thinking on having a multi-spec returning schemas, so each service can define what schema to use for an order, on a key like :service/name, but all of them can be "selected" from :order/order.

(defmulti order-schema :service/name)

(defmethod order-schema :service1
  [_]
  (spec/schema [:order/id :order/quantity :order/side :service1-order/execution-instructions]))

(defmethod order-schema :service2
  [_]
  (spec/schema [:order/id :order/quantity :order/side :service2-order/iceberg-quantity]))

(defmethod order-schema :default
  [_]
  (spec/schema [:order/id :order/quantity :order/side]))

(spec/def :order/order (spec/multi-spec order-schema :service/name))

This can be useful also when nesting objects. Imagine I have an account that will contain orders. The account can also be specced as a multi-spec for each service:

(spec/def :account/id string?)
(spec/def :account/orders (spec/coll-of :order/order))

(spec/def :service1-account/type #{:spot :margin :futures})

(defmulti account-schema :service/id)

(defmethod account-schema :service1
  [_]
  (spec/schema [:account/id :account/orders :service1-account/type]))

(defmethod account-schema :default
  [_]
  (spec/schema [:account/id :account/orders]))

(spec/def :account/account (spec/multi-spec account-schema :service/id))

This would allow to select in the following manner:

(spec/def ::service1-account-info (spec/select :account/account [:service1-account/type :account/orders {:account/orders [:order/id :order/quantity :service1-order/execution-instructions]}]))

This way, external services can specify the information they handle about the common layer domain attributes and entities, as well as specify their specific attributes. The user is able to reuse a set of common functions that operate on the common attributes, and if different services provide these common attributes, they can be used interchangeably, while keeping a way to create functions and selections that are specific to specific services.

Does this use case make sense? Is there a different way to model this that would be better?

Thanks

Spec for any map entry whose key has a spec

Sat, 12 Jun 2021 23:55:48 +0000

I need to spec map-entry-like vectors whose keys are themselves spec-ed. Each vector looks like this:

[:my.spec-ed.key/foo 42]

The specific keys used vary, and I am hoping to write a predicate that would dynamically spec any map-entry-like vector based on its key the way maps are spec-ed entry by entry via (s/keys).

In this case let's say the key is spec-ed like this:

(s/def :my.spec-ed.key/foo int?)

The best I can come up with to spec the map-entry-like vector is this:

(s/def :my.spec-ed.key/pair (s/and vector? #(s/valid? (first %) (second %))))

This works, but I don't like it because (s/explain) is not as good when something goes wrong. For example, (s/explain :my.spec-ed.key/foo "foo") is informative:

"foo" - failed: int? spec: :my.spec-ed.key/foo

Conversely, (s/explain :my.spec-ed.key/pair [:my.spec-ed.key/foo "bar"]) doesn't end up explaining what really went wrong (that I passed a string instead of an int), I have to go look up the original spec to find that out:

[:my.spec-ed.key/foo "bar"] - failed: (valid? (first %) (second %)) spec: :my.spec-ed.key/pair

Does anyone have any ideas for a better way to spec my map-entry-like vectors? For what it's worth, these vectors don't actually come from maps, and are not actually going to maps, so I can't use any of the spec functions designed to work on maps specifically.

Is the defn spec overly restrictive?

Tue, 18 May 2021 10:21:51 +0000

It seems like it should be possible to use a macro for generating a attribute map for defn but it appears as if the defn spec requires a literal map. See example below, which makes the spec fail.

   (defmacro example [f output input]
     `{:test (fn [] (is (= (~f ~input) ~output)))})

   (defn tails
     (example tails
              [1 2 3 4]
              '([1 2 3 4] (2 3 4) (3 4) (4)))
     [coll]
     (take-while some? (iterate next coll)))

 Call to clojure.core/defn did not conform to spec.
       #:clojure.spec.alpha{:problems
                            ({:path [:fn-tail :arity-1 :params],
                              :pred clojure.core/vector?,
                              :val
                              (example
                               tails
                               [1 2 3 4]
                               '([1 2 3 4] (2 3 4) (3 4) (4))),
                              :via
                              [:clojure.core.specs.alpha/defn-args
                               :clojure.core.specs.alpha/params+body
                               :clojure.core.specs.alpha/param-list
                               :clojure.core.specs.alpha/param-list],
                              :in [1]}
                             {:path [:fn-tail :arity-n :bodies :params],
                              :pred clojure.core/vector?,
                              :val example,
                              :via
                              [:clojure.core.specs.alpha/defn-args
                               :clojure.core.specs.alpha/params+body
                               :clojure.core.specs.alpha/params+body
                               :clojure.core.specs.alpha/params+body
                               :clojure.core.specs.alpha/param-list
                               :clojure.core.specs.alpha/param-list],
                              :in [1 0]}),
                            :spec
                            #object[clojure.spec.alpha$regex_spec_impl$reify__2510 0x643aeb02 "clojure.spec.alpha$regex_spec_impl$reify__2510@643aeb02"],
                            :value
                            (tails
                             (example tails [1 2 3 4] '([1 2 3 4] (2 3 4) (3 4) (4)))
                             [coll]
                             (take-while some? (iterate next coll))),
                            :args
                            (tails
                             (example tails [1 2 3 4] '([1 2 3 4] (2 3 4) (3 4) (4)))
                             [coll]
                             (take-while some? (iterate next coll)))}
                     alpha.clj:  712  clojure.spec.alpha/macroexpand-check
                     alpha.clj:  704  clojure.spec.alpha/macroexpand-check
                      AFn.java:  156  clojure.lang.AFn/applyToHelper
                      AFn.java:  144  clojure.lang.AFn/applyTo
                      Var.java:  705  clojure.lang.Var/applyTo
                 Compiler.java: 6974  clojure.lang.Compiler/checkSpecs
                 Compiler.java: 6992  clojure.lang.Compiler/macroexpand1
                 Compiler.java: 7079  clojure.lang.Compiler/macroexpand
                 Compiler.java: 7165  clojure.lang.Compiler/eval
                 Compiler.java: 7136  clojure.lang.Compiler/eval
                      core.clj: 3202  clojure.core/eval
                      core.clj: 3198  clojure.core/eval
        interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                      AFn.java:  152  clojure.lang.AFn/applyToHelper
                      AFn.java:  144  clojure.lang.AFn/applyTo
                      core.clj:  667  clojure.core/apply
                      core.clj: 1977  clojure.core/with-bindings*
                      core.clj: 1977  clojure.core/with-bindings*
                   RestFn.java:  425  clojure.lang.RestFn/invoke
        interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                      main.clj:  437  clojure.main/repl/read-eval-print/fn
                      main.clj:  437  clojure.main/repl/read-eval-print
                      main.clj:  458  clojure.main/repl/fn
                      main.clj:  458  clojure.main/repl
                      main.clj:  368  clojure.main/repl
                   RestFn.java:  137  clojure.lang.RestFn/applyTo
                      core.clj:  667  clojure.core/apply
                      core.clj:  662  clojure.core/apply
                    regrow.clj:   20  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
                   RestFn.java: 1523  clojure.lang.RestFn/invoke
        interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
        interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
        interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                      AFn.java:   22  clojure.lang.AFn/run
                   session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
                   session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                      AFn.java:   22  clojure.lang.AFn/run
                   Thread.java:  829  java.lang.Thread/run

should the docstring of `s/keys` give more information about :req-un?

Wed, 12 May 2021 03:34:53 +0000

Question came up on slack about how to validate optional keys. I was going to point them to the docstring for s/keys but found it might need some clarification. The docstring in question:

-------------------------
clojure.spec.alpha/keys
([& {:keys [req req-un opt opt-un gen]}])
Macro
  Creates and returns a map validating spec. :req and :opt are both
  vectors of namespaced-qualified keywords. The validator will ensure
  the :req keys are present. The :opt keys serve as documentation and
  may be used by the generator.

  The :req key vector supports 'and' and 'or' for key groups:

  (s/keys :req [::x ::y (or ::secret (and ::user ::pwd))] :opt [::z])

  There are also -un versions of :req and :opt. These allow
  you to connect unqualified keys to specs.  In each case, fully
  qualfied keywords are passed, which name the specs, but unqualified
  keys (with the same name component) are expected and checked at
  conform-time, and generated during gen:

  (s/keys :req-un [:my.ns/x :my.ns/y])

  The above says keys :x and :y are required, and will be validated
  and generated by specs (if they exist) named :my.ns/x :my.ns/y 
  respectively.

  In addition, the values of *all* namespace-qualified keys will be validated
  (and possibly destructured) by any registered specs. Note: there is
  no support for inline value specification, by design.

  Optionally takes :gen generator-fn, which must be a fn of no args that
  returns a test.check generator.

I had expected to see something to the effect that if the keys specified by :opt or :opt-un were present, they would be validated against the specs for those keys. Instead it only mentions that they serve as documentation.

Seemed like this could perhaps use some clarification.

spec fdef validating relationships between arguments

Mon, 19 Apr 2021 20:30:39 +0000

I have the following data structure as the state of my mini restaurant app

    {:orders {:e4d55743-c964-48e8-9cd1-cb1cf9075617 [#:helloworld.restaurant{:name "chilly parotta", :quantity 3}  #:helloworld.restaurant{:name "masal dosa", :quantity 2}]}, :menu {:kothu-parotta #:helloworld.restaurant{:name "Kothu Parotta", :price 9.5, :quantity 50},  :butter-naan #:helloworld.restaurant{:name "Butter Naan", :price 3, :quantity 50}, :paneer-butter-masala #:helloworld.restaurant{:name "Paneer Butter Masala", :price 9.5, :quantity 50}}}

I have a function to update the menu item corresponding to every order item in the order to deduct the order quantity from the inventory and return the new menu. I want to validate

The item in the order item, should exist in the menu
The item's quantity in the inventory, should be greater than the ordered quantity

I have the following specs (Note: I have not validated 2 for now). When I run this, function call to update-menu-item-for-order-item is not validating my predicate for 1. What am I doing wrong in the fdef spec?

(s/def ::name string?)
(s/def ::price number?)
(s/def ::quantity number?)
(s/def ::order-item (s/keys :req [::name ::quantity]))
(s/def ::order-items (s/coll-of ::order-item))
(s/def ::menu-item (s/keys :req [::name ::price ::quantity]))
(s/def ::menu-item-id keyword?)
(s/def ::menu (s/map-of ::menu-item-id ::menu-item))

(s/fdef restaurant-save-menu :args (s/cat :menu-items (s/coll-of ::menu-item)))

(s/fdef update-menu-item-for-order-item
        :args (s/and (s/cat :menu ::menu :order-item ::order-item)
                     #(contains? (:menu %) (keyword (slugify (::name (:order-item %))))))
        :ret ::menu)

(stest/instrument `update-menu-item-for-order-item)
(stest/instrument `restaurant-save-menu)

Can I use spec as type hint?

Sun, 11 Apr 2021 07:30:38 +0000

One cool feature of schema is that it works well with type hint,
So I can use it for validation, compiler optimization and documentation directly on the function. I'd like to know if the same could be done using specs and if possible, a real example. Thanks!

Unexpected spec failure on namespaced keys not included in :req

Thu, 18 Mar 2021 00:19:18 +0000

Hi there, I am here to report what I think is my second quirk in a week with spec instrumentation.

I apologize if it has been already reported as bug but basically I cannot understand/expected the last call to trigger an error - the ::id-map spec does not require the check on ::other after all.

(ns repro-spec.test
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as st]))

(s/def ::impl any?)
(s/def ::id string?)
(s/def ::other number?)

(s/def ::id-map (s/keys :req [::id]))

(s/fdef delete-impl
  :args (s/cat :impl ::impl
               :id-map ::id-map))

(defn delete-impl [_ id-map]
  (println (str "This deletes " (::id id-map)))
  id-map)

(st/instrument)

(delete-impl {} {::id "test"})
;; prints "This deletes test"

(delete-impl {} {::id "test" ::other "ignore me"})
;; Execution error - invalid arguments to repro-spec.test/delete-impl at (REPL:27).
;; "ignore me" - failed: number? at: [:id-map :repro-spec.test/other] spec: :repro-spec.test/other

I am doing something wrong?

Spec instrumentation does not work with extend-with-metadata

Mon, 15 Mar 2021 17:22:34 +0000

Hi there, our code base have embraced extend-with-metadata protocols since its introduction - we like to have map components rather than records.

However, the code base and team are big clojure spec users and we were expecting the last form of the following to throw:

(ns defproto-spec.test
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as st]))

(defprotocol SpecTest
  :extend-via-metadata true
  (delete [impl id]))

(s/fdef delete-impl
  :args (s/cat :impl any? :id string?))

(defn delete-impl [_ id]
  (println (str "This deletes " id))
  id)

(def impl (with-meta {} {`delete delete-impl}))

(st/instrument)

(delete impl 1) ;; should throw but it doesn't

Why were we expecting it to work?

Maybe because the feature is newer (1.10) and because of the following:

defproto-spec.test> (st/instrument)
[defproto-spec.test/delete-me defproto-spec.test/delete-impl]

Unfortunately that's not that case. I would be willing to work on a patch/document this if is not already in someone else's pipeline.

Thanks,
Andrea.

Generating a function invokes the function

Sat, 06 Mar 2021 21:55:46 +0000

I was experimenting with custom function generators in order to support the scenario describe in spec guide https://clojure.org/guides/spec#_combining_check_and_instrument but with the goal of making the generated values depend on the concrete arguments and not only on the :ret spec.

While working on that, I noticed a weird behavior that I fail to understand where a generated function is being called 21 times before actually being returned.

(require '[clojure.spec.alpha :as s]
         '[clojure.spec.gen.alpha :as gen])

(s/fdef foo
  :args (s/cat :x int?)
  :gen #(gen/return
         (fn [& argv]
           (prn argv)
           (gen/generate (s/gen string?)))))

(gen/generate (s/gen `foo))
;; Prints:
;; (-1)
;; (-1)
;; (-2)
;; (-1)
;; (3)
;; (-2)
;; (-2)
;; (-1)
;; (-35)
;; (14)
;; (-16)
;; (26)
;; (-17)
;; (150)
;; (0)
;; (-1)
;; (25)
;; (5638)
;; (543)
;; (57)
;; (257)
;; Returns: #function[fspec-gen-bug.core/fn--6577/fn--6578]

This behavior seems specific to function generation for example

(s/def ::bar
  (s/spec (s/coll-of int?)
          :gen #(gen/return
                 (doto [(gen/generate (s/gen int?))]
                   prn))))

(gen/generate (s/gen ::bar))
;; Prints:
;; [438803]
;; Returns: [438803]

Is there a good reason why generated functions are invoked eagerly ? or is it a bug ?

`cljs.spec.test.alpha/check` does not support passing lexically scoped values

Sun, 27 Dec 2020 11:30:23 +0000

Hello,

while trying to port some Clojure code to Clojurescript, I encountered a problem in my test suite when trying to check a list of function specs symbols using cljs.spec.test.alpha/check.

Here is a small scenario to reproduce the issue:

`
(ns spec.check.problem
(:require
[clojure.spec.alpha :as s]
[clojure.spec.gen.alpha :as gen]
[clojure.spec.test.alpha :as stest]
[clojure.test.check]
[clojure.test.check.properties]))

(defn foo
[x]
(inc x))

(s/fdef foo
:args (s/cat :x int?)
:ret int?)

(def list-of-specs
`[foo])

(stest/check `[foo]) ; => OK

(stest/check list-of-specs) ; => Unable to resolve symbol: list-of-specs in this context
`

The above example work with Clojure but not with ClojureScript. Is that intended or is this a bug ?

I have used Clojure 1.10.1 and Clojurescript 1.10.758 for my tests.

Using (s/or) without destructuring

Sun, 22 Nov 2020 19:20:02 +0000

I have a sequence of characters, and am trying to use (s/cat ...) with (s/or) in order to conform the sequence.

The input could look something like [0 1 2 3] or [\a \b \c \d] and I am trying to use this spec.

(s/conform (s/cat :top (s/or :nums (s/+ #{0 1 2 3 4})
                             :letters (s/+ #{\a \b \c \d})
                  ... more stuff))
           [0 1 2 3])
=> :clojure.spec.alpha/invalid

Not using the (s/or) works if I choose one of :nums or :letters.

(s/conform (s/cat :first-set (s/+ #{0 1 2 3 4}))
           [0 1 2 3])
=> {:first-set [0 1 2 3]}

The initial example works if the entire sequence is wrapped in another vec, but this isn't what I want.

(s/conform (s/cat :first-set (s/or :nums (s/+ #{0 1 2 3 4})
                                   :letters (s/+ #{\a \b \c \d})))
           [[0 1 2 3]])
=> {:first-set [:nums [0 1 2 3]]}

Using (or ...) also seems to only work inside (s/keys). I'm guessing it's because the (or always takes the first spec because it's not falsy.

(s/conform (s/cat :first-set (or (s/+ #{0 1 2 3 4})
                                 (s/+ #{\a \b \c \d})))
           [0 1 2 3])
=> {:first-set [0 1 2 3]}

(s/conform (s/cat :first-set (or (s/+ #{0 1 2 3 4})
                                 (s/+ #{\a \b \c \d})))
           [\a \b \c])
=> :clojure.spec.alpha/invalid

This is what I want to happen.

(s/conform (s/cat :first-set (s/something-here (s/+ #{0 1 2 3 4})
                                               (s/+ #{\a \b \c \d})))
           [0 1 2 3])
=> {:first-set [0 1 2 3]}

(s/conform (s/cat :first-set (s/something-here (s/+ #{0 1 2 3 4})
                                               (s/+ #{\a \b \c \d})))
           [\a \b \c])
=> {:first-set [\a \b \c]}

I'm wondering what to do here.

signal an error on mulimethod without a dispatch function?

Wed, 28 Oct 2020 20:09:35 +0000

user=> (defmulti thing)
#'user/thing
user=> (defmethod thing :default [x] :hi)
#object[clojure.lang.MultiFn 0x7b60c3e "clojure.lang.MultiFn@7b60c3e"]
user=> (thing :hello)
Execution error (NullPointerException) at user/eval144 (REPL:1).
null
user=>

Someone was surprised by this behavior and missed the error that there was no dispatch function defined. Notable that there is some validation for defmulti:

 (defmulti thing [x] (fn [x] x))
Syntax error macroexpanding defmulti at (REPL:1:1).
The syntax for defmulti has changed. Example: (defmulti name dispatch-fn :default dispatch-value)
user=>

function spec challenge

Wed, 07 Oct 2020 03:38:56 +0000

What is the simplest way to spec this function? Specifically, the :fn portion

(s/def ::edges #{0.149 0.150 0.050})
(s/def ::result #{:correct :incorrect})

(s/fdef foo
        :args (s/cat :student-response ::edges :authoritative-answer ::edges)
        :ret ::result
:fn ? )

Basically, if the student-response rounded to the tenths place matches the authoritative-answer rounded to the tenths place, the function returns :correct, otherwise :incorrect.

I selected edges that would hit the rounding boundaries rather than hoping the generative process for numbers would stumble on those edges.

Has the destructuring spec changed since 1.8.0?

Fri, 25 Sep 2020 15:24:01 +0000

1.8.0:

clj-rcon-test.core=> (defn- hi [as-codec & {:keys [offset] :or {:offset 0}}]
                #_=>   (println "hi"))
#'clj-rcon-test.core/hi

1.10.0:

clj-rcon-test.core=> (defn- hi [as-codec & {:keys [offset] :or {:offset 0}}]
                #_=>   (println "hi"))
Syntax error macroexpanding clojure.core/defn- at (form-init17556793069765460591.clj:1:1).
:offset - failed: simple-symbol? at: [:fn-tail :arity-1 :params :var-params :var-form :map-destructure :or 0] spec: :clojure.core.specs.alpha/or
{:keys [offset], :or {:offset 0}} - failed: simple-symbol? at: [:fn-tail :arity-1 :params :var-params :var-form :local-symbol] spec: :clojure.core.specs.alpha/local-name
{:keys [offset], :or {:offset 0}} - failed: vector? at: [:fn-tail :arity-1 :params :var-params :var-form :seq-destructure] spec: :clojure.core.specs.alpha/seq-binding-form
as-codec - failed: vector? at: [:fn-tail :arity-n :bodies :params] spec: :clojure.core.specs.alpha/param-list

clj-rcon-test.core=>

For context this is what I'm trying to troubleshoot: https://github.com/gpittarelli/clj-rcon/blob/master/src/clj_rcon/codecs.clj#L6

Missing error on silly destructuring mistake

Wed, 09 Sep 2020 07:32:08 +0000

I happened to define a function like this

(defn foo [{:keys [bar :as lol]}] lol)

Obviously the destructuring is wrong, it should have been

(defn foo [{:keys [bar] :as lol}] lol)

My question is then, should this destructuring error be caught by the specs for destructuring?

What is a good place to start for implementing a new Clojure backend?

Fri, 04 Sep 2020 19:29:34 +0000

I've done some digging around for a spec, test suite, or some scraps of documentation to inform the development of a Clojure backend. Most of my searching has only turned up other implementations that are mostly doing their own thing - even ClojureScript doesn't seem to have any way to verify conformance with what Clojure should be. And from what I understand, ClojureCLR works largely because it was a (mostly) one-to-one clone of the Java source code in C#.

Is there a preferred, or maintainer recommended, way to go about developing a new backend for Clojure? Or is that considered 'wild' territory?

Is there a way to find there was a name collision for keywords?

Tue, 21 Jul 2020 16:01:35 +0000

Recently, I found a bug in a project from the company I work at.

Basically, what was happening was that inside a test's namespace we required two different namespaces, let's call them first-ns and second-ns here.

Both first-ns and second-ns had the definition of a spec with the same name, like this:

(ns first-ns)
(s/def :same/name
    int?)

(ns second-ns)
(s/def :same/name
    string?)

So my question is, is there a way to make the Clojure compiler complain about a name clash for cases like this? In large codebases with hundreds of specs, this can occasionally happen and cause a heisenbug. Is the only solution to make the specs namespaced to the same ns of the file in which they were defined?

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?

How to get the req-un/opt-un of a keys spec?

Mon, 15 Jun 2020 22:33:18 +0000

I want to create a spec that is like spec/keys, but that enforces that only keys in req-un and opt-un are allowed.

I was told that there is no easy way to do that with clojure.spec.alpha, and that I need to add an s/and with a function that will check that the given keys exist in req-un and opt-un.

My plan is to simply create another spec using the spec already defined with spec/keys, since it seems to me that it's impossible to define that the spec is exhaustive in one single spec. So what I want is something like this:

(spec/def ::person (spec/keys :req-un [::name ::age]))
(spec/def ::person-exhaustive (s/and ::person #(only-allowed-keys %))

However, it is not clear to me how to do that properly. I noticed there is a spec/form function that returns the spec as data, but since it is a Cons it seems clunky to use it. Is there a better way to get that data from a spec?

Exhaustive spec checking like spec/keys, how?

Tue, 26 May 2020 17:59:15 +0000

My understanding is that spec/keys works for validating specific keys in a hash-map. However, I need it to also reject a hash-map that contains keys that are not in :req and :opt.

For a contrived example, imagine I have a definition of a person as an edn:

{:name "John"
:age 25}

The spec could be:

(spec/def ::name string?)
(spec/def ::age int?)
(spec/def ::person (spec/keys :req-un [::name ::age]))

The above definition would conform to this ::person spec.

However, let's say that, due to a confusion by a developer, another key unrelated to a Person's definition was added, and the hash-map is now:

{:name "John"
:age 25
:voltage 220}

That would still conform to the spec. But I want it to fail!

Is there a simple way to make spec/keys reject a hash-map that has keys that are neither req nor opt?

Clojure tradeoffs and how do we mitigate them?

Sat, 25 Apr 2020 23:49:49 +0000

Earlier this week I conversed with a person who had decided to stop using Clojure, I have summarized their points. Before we grab our pitchforks to go after any party here, I am more curious about what we can do to mitigate these tradeoffs if you agree with them. What have you tried? What's your experience? What's your advice?

I feel it's important to state my goal is not to be critical of anyone's work here. I LOVE Clojure and I find this person's insight motivates me to learn about Clojure's trade-offs and explore how to address them using the plethora of tools already at our disposal.

Below is a summary of that person's issues followed by my own thoughts.

REPL driven development

Felt like a work-around to the slow startup problem
REPL dev was not productive. Often encountered broken REPL states requiring a restart.

Clojure

No static types.
How do you know what keys and values are within a map?

Spec

Too verbose. It seems to contradict the conciseness that Clojure typically embraces.
A lot of legwork required to get value from spec requiring you to write many predicates, s/ forms, checkers, etc...

My thoughts:

Startup time of CLJS or CLJ hasn't felt like much of a barrier to me in development but GRAAL could be a good solution.
I haven't encountered as much broken REPL state with Clojure but it definitely happens frequently with CLJS and Shadow. Is this something we can mitigate using libraries like Integrant or Component? What often leads to an inconsistent state?
As for static typing, I can see why it's a goto solution for knowing what a map contains but aside from spec how can we address it in our code?
Since speaking to this person I have observed there are many times where I'm executing in the REPL just to find out what data I have.
Should we be adding more docs to our functions to specify which keys we need? Could we make better use of destructuring to help emphasize expected keys? Are there better tooling mechanisms to help with this?
I don't have any issues with spec myself but I'm not the most experienced with it.
What I like is that you are constructing a DSL to specify the relationships in your domain logic which seems advantageous to me over static typing which brings all problems down to a comp-sci academic level.
Do I really need to know if this lead I'm trying to send to a vendor in my marketplace is a Record Type?

What are your thoughts?

Exercising selection of union of specs throws error

Tue, 11 Feb 2020 20:40:50 +0000

I was trying to exercise a spec which is a union of two others with a selection

(ns example
(:require [clojure.alpha.spec :as s]))

(s/def ::val1 int?)
(s/def ::foo (s/schema [::val1]))

(s/def ::val2 int?)
(s/def ::bar (s/schema [::val2]))

(s/def ::foobar (s/union ::foo ::bar))

(s/exercise (s/select ::foobar [::val1]))

But this throws an error.

No implementation of method: :keyspecs* of protocol:
#'clojure.alpha.spec.protocols/Schema found for class:
clojure.alpha.spec.impl$union_impl$reify__7091

Should select work for this? Or am I doing something wrong?

I am using

org.clojure/alpha.spec {:git/url "https://github.com/clojure/spec-alpha2.git"
                             :sha "495e5ac3238be002b4de72d1c48479f6bec06bb3"}

Sharing specs between modules

Wed, 15 Jan 2020 11:23:04 +0000

I'm relatively new to Clojure/Spec and having read the documentation it's not immediatly obvious to me whether it is best practice is to (re)declare specs within the module they validate to or whether it is better to declare common specs seperatly for reuse across multiple modules.

For example, a game might have many different objects that all need a position consisting of x, y coordinates. In this repo for example the ::x and ::y spec defs are redeclared in each "entity" module (clouds, explosions etc). Is this preferred to having a single spec for position and importing accross modules?

Select one spec from multi-spec

Wed, 06 Nov 2019 18:00:39 +0000

What would be the preferred way to select one spec from multi-spec? E.g.

(defmulti entity :entity)

(s/def ::e1
  (s/keys :req [:e1/attr1
                :e1/attr2
                :e1/attrN]))

(defmethod entity :e1 [_] ::e1)

(s/def ::e2
  (s/merge
   ::e1
   (s/keys :req [:e2/attr1
                 :e2/attr2
                 :e2/attrN])))

(defmethod entity :e2 [_] ::e2)

(s/def ::entity (s/multi-spec entity :entity))

How to spec a function that accepts only ::e2 entity as an argument? ... or how to generate only ::e2 entity values?

Can't do (s/cat :e2 ::e2) or (s/gen ::e2) because ::e2 doesn't have the required :entity tag. Also, can't add :req-un [:e1/entity] and :req-un [:e2/entity] to ::e1 and ::e2 because it would clash in the s/merge.

The simplest way I've found is to use s/and, e.g:

(gen/generate (s/gen (s/and ::entity ::e2)))

But it is still hard to generate data for functions that accept homogeneous collection of any entity:

(s/and (s/coll-of ::entity :min-count 1)
       #(->> % (map :entity) (apply =)))

It would be easier if you could pass the entity tag to select the specific entity spec or it's generator, e.g. generate random entity and based on it's entity tag generate other elements.

In other words, I am looking for a way to get ::e2 entity spec via :e2 tag somehow, without maintaining a global helper map...

Or is there any other solution?

Spec with nested "or" fails unexceptedly

Wed, 23 Oct 2019 12:52:41 +0000

I am trying to write a spec for existing data. The moment I try to put one spec that contains an or into other it stops working. We are using confrom quite extensively so being able to get the or labels is important.
`

(s/def :a/b int?)
(s/def ::inner (s/or
                 :ident (s/tuple #{:a/b} :a/b)
                 :temp string?))
(s/def ::one int?)
(s/def ::two int?)
(s/def ::outer (s/and
            (s/keys :req [::inner])
                 (s/or
                  :one (s/keys :req [::one])
                  :two (s/keys :req [::two]))))
(s/valid? ::outer {::inner [:a/b 1]
               ::one 1})

In the examle above if ::inner is just the spec under the :ident branch of the or then spec sees it as valid, but the moment there are two or specs involved it breaks.

Is there another way I'm supposed to construct specs such as these?