Clojure Q&A - Recent questions in 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.

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!

`(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 %))

Surprising behaviour

Mon, 23 Oct 2023 14:04:51 +0000

I am trying to learn spec, and have come across the following behaviour.

My code:

(s/def ::foo (s/cat :first symbol?
                :rest (s/alt :simple vector?
                             :multi (s/cat :parts (s/* symbol?) :final vector?))))
(s/explain ::foo '(foo [blah] x))
(s/conform ::foo '(foo [blah] x))

What I find is that s/explain prints "Success!" while s/conform returns :s/invalid.
Have I stumbled on a bug, or have I not understood the functions?
Or is my spec invalid in the first place?
(I am using Clojure 1.11.1 & spec 0.3.218)

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 :--) )

Should the actual function be called when an fspec is being validated?

Mon, 29 May 2023 17:11:04 +0000

TL;DR
When instrumentation is turned on, spec validates a fspec that appears in the :args of another fspec by calling the actual function with generated arguments, which if it performs side effects could lead to unexpected and incorrect results.

The problem
If we have the following functions and specs

(defn create-generator []
  (let [counter (atom [])]
    (fn [& _]
      (swap! counter inc))))

(s/def ::my-generator (s/fspec :args (s/cat :identifier-arguments (s/* string?))
                               :ret integer?))

(defn my-fn [generator]
  (generator))

(s/fdef my-fn
        :args (s/cat :my-context ::my-generator)
        :ret string?)

Calling (my-fn (create-generator)) will return different results depending on instrumentation being enabled or not.
With instrumentation enabled, our function is being called 21 times more than the single invocation we'll be expecting (hint: this numbers comes from clojure.alpha.spec/fspec-iterations).
This happens because my-fn's spec has args, and in such case clojure.alpha.spec.test/instrument does the following:

If a var has an :args fn-spec, sets the var's root binding to a fn
that checks arg conformance (throwing an exception on failure) before
delegating to the original fn.

This means it must check if the function received as argument conforms the ::my-generator spec, which is itself an fspec. For that it calls the fspec reified conform* and that implementation runs a quick-check style test, generating random arguments based on the :args spec and calling the actual function. This can be observed by creating an exception in the function returned by create-generator, the stacktrace looks like this

'[[clojure.test_clojure.fspec_bug_test$create_generator$fn__5468 doInvoke "fspec_bug_test.clj" 4]
  [clojure.lang.RestFn applyTo "RestFn.java" 137]
  [clojure.core$apply invokeStatic "core.clj" 665]
  [clojure.core$apply invoke "core.clj" 660]
  [clojure.alpha.spec.impl$call_valid_QMARK_ invokeStatic "impl.clj" 1616]
  [clojure.alpha.spec.impl$call_valid_QMARK_ invoke "impl.clj" 1612]
  [clojure.alpha.spec.impl$validate_fn$fn__4117 invoke "impl.clj" 1627]
  [clojure.lang.AFn applyToHelper "AFn.java" 154]
  [clojure.lang.AFn applyTo "AFn.java" 144]
  [clojure.core$apply invokeStatic "core.clj" 665]
  [clojure.core$apply invoke "core.clj" 660]
  [clojure.test.check.properties$apply_gen$fn__5403$fn__5404 invoke "properties.cljc" 31]
  [clojure.test.check.properties$apply_gen$fn__5403 invoke "properties.cljc" 30]
  [clojure.test.check.rose_tree$fmap invokeStatic "rose_tree.cljc" 77]
  [clojure.test.check.rose_tree$fmap invoke "rose_tree.cljc" 73]
  [clojure.test.check.generators$fmap$fn__4871 invoke "generators.cljc" 104]
  [clojure.test.check.generators$gen_fmap$fn__4845 invoke "generators.cljc" 59]
  [clojure.test.check.generators$call_gen invokeStatic "generators.cljc" 43]
  [clojure.test.check.generators$call_gen invoke "generators.cljc" 39]
  [clojure.test.check$quick_check invokeStatic "check.cljc" 211]
  [clojure.test.check$quick_check doInvoke "check.cljc" 59]
  [clojure.lang.RestFn invoke "RestFn.java" 425]
  [clojure.lang.AFn applyToHelper "AFn.java" 156]
  [clojure.lang.RestFn applyTo "RestFn.java" 132]
  [clojure.core$apply invokeStatic "core.clj" 665]
  [clojure.core$apply invoke "core.clj" 660]
  [clojure.alpha.spec.gen$quick_check invokeStatic "gen.clj" 32]
  [clojure.alpha.spec.gen$quick_check doInvoke "gen.clj" 30]
  [clojure.lang.RestFn invoke "RestFn.java" 421]
  [clojure.alpha.spec.impl$validate_fn invokeStatic "impl.clj" 1628]
  [clojure.alpha.spec.impl$validate_fn invoke "impl.clj" 1623]
  [clojure.alpha.spec.impl$fspec_impl$reify__4124 conform_STAR_ "impl.clj" 1646]
  [clojure.alpha.spec$conform invokeStatic "spec.clj" 245]
  [clojure.alpha.spec$conform invoke "spec.clj" 237]
  [clojure.alpha.spec$conform invokeStatic "spec.clj" 241]
  [clojure.alpha.spec$conform invoke "spec.clj" 237]
  [clojure.alpha.spec.impl$dt invokeStatic "impl.clj" 219]
  [clojure.alpha.spec.impl$dt invoke "impl.clj" 214]
  [clojure.alpha.spec.impl$dt invokeStatic "impl.clj" 215]
  [clojure.alpha.spec.impl$dt invoke "impl.clj" 214]
  [clojure.alpha.spec.impl$deriv invokeStatic "impl.clj" 1426]
  [clojure.alpha.spec.impl$deriv invoke "impl.clj" 1420]
  [clojure.alpha.spec.impl$deriv invokeStatic "impl.clj" 1434]
  [clojure.alpha.spec.impl$deriv invoke "impl.clj" 1420]
  [clojure.alpha.spec.impl$re_conform invokeStatic "impl.clj" 1564]
  [clojure.alpha.spec.impl$re_conform invoke "impl.clj" 1555]
  [clojure.alpha.spec.impl$as_regex_spec$fn__3849 invoke "impl.clj" 1238]
  [clojure.alpha.spec.protocols$eval1958$fn__2056$G__1939__2067 invoke "protocols.clj" 11]
  [clojure.alpha.spec$conform invokeStatic "spec.clj" 245]
  [clojure.alpha.spec$conform invoke "spec.clj" 237]
  [clojure.alpha.spec$conform invokeStatic "spec.clj" 241]
  [clojure.alpha.spec$conform invoke "spec.clj" 237]
  [clojure.alpha.spec.test$spec_checking_fn$conform_BANG___4398 invoke "test.clj" 131]
  [clojure.alpha.spec.test$spec_checking_fn$fn__4400 doInvoke "test.clj" 150]
  [clojure.lang.RestFn invoke "RestFn.java" 408]
  [clojure.test_clojure.fspec_bug_test$eval5473 invokeStatic "fspec_bug_test.clj" 2]
  [clojure.test_clojure.fspec_bug_test$eval5473 invoke "fspec_bug_test.clj" 44]
  ...]

Of course, the problem can be reduced to the fspec implementation of conform* since by just calling s/valid? will show the behavior of the function being called, but this is uncommon, while having functions annotated and turning on instrumentation during tests is a common practice, that's why the example in this PR shows a concrete problematic scenario with the current implementation of fspec.

; This already shows the actual function being called, but is an unrealistic example
(s/valid? ::my-generator (fn [& args]
                           (println args)
                           1))

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

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.

(s/valid? ::my-spec) succeeds, but (s/valid? (s/and ::my-spec ::my-spec)) fails

Wed, 08 Mar 2023 20:09:35 +0000

It seems like if ::my-spec validates, then (s/and ::my-spec ::my-spec) should also validate.

This is a simplified version of my actual code, but I'm running into problems validating some data that is spec'd using a combination s/and, s/keys, and s/or. This is the smallest reproduction I could come up with.

(s/def :a/coordinate
  (s/or :double double?
        :int int?))
(s/valid?
 (s/keys)
 {:a/coordinate 1.0})
;; true

(s/valid?
 (s/and (s/keys))
 {:a/coordinate 1.0})
;; true

(s/valid?
 (s/and (s/keys)
        (s/keys))
 {:a/coordinate 1.0})
;; false

(s/explain-str
 (s/and (s/keys)
        (s/keys))
 {:a/coordinate 1.0})
;; "[:double 1.0] - failed: double? in: [:a/coordinate] at: [:a/coordinate :double] spec: :a/coordinate\n[:double 1.0] - failed: int? in: [:a/coordinate] at: [:a/coordinate :int] spec: :a/coordinate\n"

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.

Is it useful to extend fspec to enable the expression of constraints on a function such as commutativity.

Sun, 27 Nov 2022 19:36:21 +0000

Does it seem useful to add a new kwarg to fspec to allow a function spec to provide one or more constraints on or invariants of the function across distinct invocations in order to provide for constraints such as commutativity. I am working on this, but thought good to check if anyone else thinks is useful.

The new kwarg, possibly :alg given that this allows expression of the algebraic properties of the function, would take a map, with key being a naming keyword and value being a predicate (typically needing a let).

Looking somewhat like this for a few binary operators:

(s/fdef add

:args (s/cat :x int? :y int?)
:ret int?
:alg { :comm

        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)]
               (= ((f x y) (f y x))

        :assoc 
        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)
                z  (-> % args :x)]
                (= (f (f x y) z) (f x (f y z)))

        :ident   
        (let [f (:f %)
                x (-> % args :x)]
               (= (f x 0) x))})

(s/fdef mul
:args (s/cat :x int? :y int?)
:ret int?
:alg { :comm

        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)]
               (= ((f x y) (f y x))

        :assoc 
        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)
                z  (-> % args :x)]
                (= (f (f x y) z) (f x (f y z)))

        :ident   
        (let [f (:f %)
                x (-> % args :x)]
               (= (f x 0) x))

        :super
        (let [f (:f %)
                x (-> % args :x)]
               (= (f x 0) 0))})

(s/fdef max
:args (s/cat :x int? :y int?)
:ret int?
:alg { :comm

        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)]
               (= ((f x y) (f y x))

        :assoc 
        (let [f (:f %)
                x  (-> % args :x)
                y  (-> % args :x)
                z  (-> % args :x)]
                (= (f (f x y) z) (f x (f y z)))

        :idem
        (let [f (:f %)
                x (-> % args :x)]
                (= (f x x) x)})

:ident, :super and :idem above could obvs be done with :fn, but seems handy to put together once one gets :comm and :assoc in place.

This may give rise to question of how to similarly handle constraints on or invariants of sets of related functions, although probably less commonly useful. However that may suggest that actually this would be better done as separate from the fspec in a separate spec - ?

How hard is it to learn Clojure?

Fri, 28 Oct 2022 23:28:38 +0000

It had been a couple of weeks since I've started learning Clojure.

I am a newbie at programming and I passed some basic courses here about Java. I just wanted to know how long it will take for me to learn Clojure and if is it difficult for beginners. Also, you can recommend your favourite resources and roadmaps.

Thanks in advance!

Typo in clojure.spec.alpha’s keys docstring

Mon, 03 Oct 2022 12:04:28 +0000

Line 428 reads “fully qualfied keywords”—it should be “qualified”.

Spec2 - Bug on nested schema specs

Wed, 21 Sep 2022 18:07:48 +0000

I would like to extend issue https://clojure.atlassian.net/browse/CLJ-2648 by stating that generate/valid?/exercise all dont work for any schema spec with a nested schema spec on it.

(s/def :another-entity/id uuid?)
(s/def :another-entity/some-attr int?)
(s/def ::another-entity (s/schema [:another-entity/id :another-entity/some-attr]))

(s/def :entity/id uuid?)
(s/def :entity/another-attr string?)
(s/def :entity/ref ::another-entity)
(s/def ::complex-entity (s/schema [:entity/id :entity/another-attr :entity/ref]))

(s/valid? ::complex-entity {:entity/id (random-uuid)
                            :entity/another-attr "oi"})
;;=> true
(s/valid? ::complex-entity {:entity/id (random-uuid)
                            :entity/another-attr "oi"
                            :entity/ref #:another-entity{:id (random-uuid)}})
;;=> Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1960$fn$G (protocols.clj:11).
;    No implementation of method: :conform* of protocol: #'clojure.alpha.spec.protocols/Spec found for class: clojure.lang.Keyword

(generators/generate (s/gen ::complex-entity))
;;=> Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1960$fn$G (protocols.clj:11).
;    No implementation of method: :conform* of protocol: #'clojure.alpha.spec.protocols/Spec found for class: clojure.lang.Keyword

Thanks :)

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 2: Closed Generators

Mon, 12 Sep 2022 08:36:26 +0000

Hello,

is it possible to get a "closed" generator from a `s/select` form
and/or make it the default in Spec 2?

From the example in the Wiki:

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

(s/def ::id int?)
(s/def ::first string?)
(s/def ::last string?)
(s/def ::user (s/schema [::id ::first ::last ::addr]))

(s/def ::my-user (s/select ::user [::id]))

(s/exercise ::my-user)

This generates users that have more keys than what I selected:

([#:user{:id 0} #:user{:id 0}]
 [#:user{:addr #:user{:city "1"}, :first "O", :id 0}
  #:user{:addr #:user{:city "1"}, :first "O", :id 0}])

I believe it is the same data which the `s/schema` for the `::user`
spec generates. My guess is this just hasn't been implemented yet.

Would it be possible to support this?

Clojure Spec 2. Unexpected s/with-gen behaviour

Fri, 09 Sep 2022 10:49:50 +0000

When using regular expression operators (s/alt s/cat etc ) to describe sequences, s/with-gen doesn't work as I would have expected. It completely ignores the generator passed to the definition. Eg:

(require '[clojure.alpha.spec :as s])
(require '[clojure.alpha.spec.gen :as gen])
(s/def ::some-spec 
 (s/with-gen string? (constantly (gen/return "olar"))))

(gen/sample (s/gen ::some-spec))
 ;;=> ("olar" "olar" "olar" "olar" "olar" "olar" "olar" "olar" "olar" "olar")

The above generator works as I would expected, now if we try to create a similar one for s/alt we get unexpected results:

(s/def ::some-other-spec 
 (s/with-gen
  (s/alt :greetings #{:olar :oizito :oi :hello :hey :yo :hallo}
             :farewell #{:bye :bye-bye :hasta-la-vista :tchussy :tchau-kakao})
  (constantly (gen/return [:tchau-kakao]))))

(gen/sample (s/gen ::some-other-spec))
;;=> => ([:olar] [:hasta-la-vista] [:hallo] [:hallo] [:tchussy] [:oi] [:bye-bye] [:tchussy] [:tchau-kakao] [:yo])

Is this a bug or is it expected somehow?

Is Clojure is the only Lisp designed with Concurrency?

Fri, 26 Aug 2022 05:21:19 +0000

I believe that Clojure is not the only Lisp build in with concurrency. From what I understand, LispWorks and perhaps Allegro Lisp is also concurrent in design. As for whether the Eclipse Lisp plug-in is concurrent, I am not sure as it relies on SBCL or CLISP for the environment. And Racket is also another Lisp dialect which Prof Matthias Felleisen has assured me that it is also a AI language, but as for concurrency I am not too sure. I believe the way forward other than create a new fork with Clojure would be better to engage the Lisp steering committee to change/add concurrency into the Common Lisp language.

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?

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. :)

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!!

Why does s/conform transform data?

Sat, 30 Oct 2021 09:05:37 +0000

I'm tinkering away with spec and I don't understand part of the design. There doesn't seem to be a good mechanism to express "this value satisfies a series of specs simultaniously".

and from clojure.core isn't useful, because then s/explain will not dig in to figure out which specific spec a data structure failed to meet.
s/and is actually a series of transforms and the logical value depends on the order of the arguments. I don't want to deal with that risk. I include a silly example a bit like what I was bitten by

Start with:

(s/def :example/s1 vector?)
(s/def :example/s2 vector?)
(s/def :example/spec (s/and :example/s1 :example/s2))
(s/valid? :example/spec [1 2 3]) ; => true

then change :example/s1 to:

(s/def :example/s1 (s/cat :a integer? :b integer? :c integer?))

now:

(s/valid? :example/spec [1 2 3]) ; => false

This put me in a position of trying to debug a spec which was a horrible experience; I don't want to be in that situation again. It isn't obvious to me how I would even start if the spec was more baroque and so I'd rather avoid functions that can transform/conform the data mid way through completely unless that is clearly required.

s/every seems fundamentally unsafe for general use - despite the name it doesn't check that a spec is true for every entry. I have functions that extend long vectors with new entries and a spec based on s/every will specifically not check the values that are most likely to contain bugs.

I'm in a position where I feel pressure to re-implement s/every (to be comprehensive) or s/and (to be validating but non-conforming) - but this is a bit confusing to me because I had just assumed what I wanted would be the common use case. Have I missed something? Why didn't a non-conforming variant of s/and get included in spec?

s/conform of s/map-of does not conform keys, is that expected?

Thu, 28 Oct 2021 14:51:23 +0000

If I run

(s/conform
 (s/map-of (s/or :keyword keyword? :string string?) any?)
 {:a 1})

I get

{:a 1}

instead of

{[:keyword :a] 1}

Is that expected?

One consequence of that is that if I try to s/unform

(s/unform
 (s/map-of (s/or :keyword keyword? :string string?) any?)
 {:a 1})

I get an exception, because :a is not a valid conformed value for s/or.

I bumped into this issue using spec-tools. Its implementation of explain-data calls s/unform (https://github.com/metosin/spec-tools/blob/master/src/spec_tools/core.cljc#L446). I'm trying to figure out whether this is a spec or spec-tools issue.

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?

(s/form (s/multi-spec ...)) returns a list with non-symbolic objects

Tue, 24 Aug 2021 11:08:11 +0000

My understanding is that s/form is expected to return symbolic lists that can be passed to eval. Forms of multi-spec specs don't behave that way, returning retag as evaluated value (e.g. a function instance).

(defn retag [x v]
  (assoc (vec x) 0 v))

(defmulti command first)

(s/form (s/multi-spec command retag))
=> (clojure.spec.alpha/multi-spec 
    current.ns/command
    #object[current.ns$retag 0x708d0436 current.ns$retag@708d0436])

;; should be something like
=> (clojure.spec.alpha/multi-spec 
    current.ns/command 
    current.ns/retag)

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.

fdef's on internal/private functions

Mon, 26 Apr 2021 17:03:25 +0000

Is it expected that st/instrument can be enabled for all fdef'ed functions (e.g., (st/instrument))? For example, say a library has a public API calling some internal functions that are spec'ed with fdef's. If the fdefs are included in the published library, is it expected that calls to those internal functions calls should pass their fdef'ed specs even though they are internal? Take the below example code.

(ns my-lib.impl
  (:require
    [clojure.spec.alpha :as s]))

(defn- do-internal-thing
  [x]
  x)

(s/fdef do-internal-thing
  :args (s/cat :x number?))

(ns my-lib.api
  (:require
    [clojure.spec.alpha :as s]
    [my-lib.impl :as impl]))

(defn do-thing
  [y]
  (impl/do-internal-thing "oops"))

If I call the api function do-thing, I will get an instrumentation exception on the call to impl/do-internal-thing. Should users of Spec's instrumentation be expected to filter out some set of fdef'ed functions and pass that filtered list to st/instrument or is this something the library should be expected to maintain? Maybe libraries should not include fdefs on internal functions?

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)

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.

Problems with s/union

Mon, 15 Mar 2021 09:49:01 +0000

While playing around with spec2, I'm seeing the following behavior which seems like a bug:

(s/def ::s1 (s/schema {:a string?}))
=> :dev.fp.livingdocs.specs/s1
(s/def ::s2 (s/schema {:b string?}))
=> :dev.fp.livingdocs.specs/s2
(s/def ::s3 (s/schema {:c string?}))
=> :dev.fp.livingdocs.specs/s3

;; The following is unexpected (neseted unions)
(s/def ::u (s/union ::s1 (s/union ::s2 ::s3)))
Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1665$fn$G     (protocols.clj:20).
No implementation of method: :keyspecs* of protocol: #'clojure.alpha.spec.protocols/Schema found for class: clojure.lang.PersistentList
(s/def ::u (s/union (s/union ::s1 ::s2) ::s3))
Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1665$fn$G (protocols.clj:20).
No implementation of method: :keyspecs* of protocol: #'clojure.alpha.spec.protocols/Schema found for class: clojure.lang.PersistentList

;; if I try to pull out the nested union into a separate keyword, it starts working 
(s/def ::u' (s/union ::s1 ::s2))
=> :dev.fp.livingdocs.specs/u'
(s/def ::u (s/union ::u' ::s3))
=> :dev.fp.livingdocs.specs/u
(s/explain (s/select ::u [:a :c]) {:a "bdfd"})
{:a "bdfd"} - failed: (fn [m] (contains? m :c))

;; but also this
(s/form ::ld/typed)
=>
(clojure.alpha.spec/schema
 [{:name clojure.core/string?, :type clojure.core/string?}])
(s/form ::ldd/editable)
=>
(clojure.alpha.spec/schema
 [{:optional clojure.core/boolean?,
   :maxLength clojure.core/integer?,
   :plainText clojure.core/boolean?,
   :excluexcludeFromTextCount clojure.core/boolean?}])
 
(s/def ::service
  (s/or :single (s/select (s/union ::ld/typed ::ldd/editable) [:type :name :optional])
         :multiple (s/select (s/union :ld/typed ::ldd/editable) [:type :name :maxLength])))
Execution error (IllegalArgumentException) at clojure.alpha.spec.protocols/eval1665$fn$G (protocols.clj:20).
No implementation of method: :keyspecs* of protocol: #'clojure.alpha.spec.protocols/Schema found for class: clojure.lang.PersistentList

In both cases s/union shows up in a nested position inside a form passed to a spec macro.

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 ?

s/unform using spec containing (s/? (s/cat ,,,)) returns an invalid value (spec 1)

Tue, 24 Nov 2020 22:06:42 +0000

While speccing a library I'm working on I tripped on a bheavior of s/unform in combination with s/? which I find odd:

(require '[clojure.core.specs.alpha :as cs])

(def binding-form '[a b :as c])

(def x (s/conform ::cs/seq-binding-form binding-form))
;; x => {:forms [[:local-symbol a] [:local-symbol b]], :as-form {:as :as, :as-sym c}}

(s/unform ::cs/seq-binding-form x) 
;; => (a b (:as c))

(s/valid? ::cs/seq-binding-form (s/unform ::cs/seq-binding-form x))
;; => false

Is this intended behavior? On intuition, I was expecting first unforming would produce the original form and also that the result of unform would validate (using the same spec).

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.

spec2 does not allow fn as retag in multi-spec

Tue, 10 Nov 2020 09:46:25 +0000

NB this is specifically a problem with spec-alpha2

We'll use the example from the multi-spec example from the tutorial:

(spec2/def :event/type keyword?)
(spec2/def :event/timestamp int?)
(spec2/def :search/url string?)
(spec2/def :error/message string?)
(spec2/def :error/code int?)

(defmulti event-type :event/type)
(defmethod event-type :event/search [_]
  (spec2/keys :req [:event/type :event/timestamp :search/url]))
(defmethod event-type :event/error [_]
  (spec2/keys :req [:event/type :event/timestamp :error/message :error/code]))

(spec2/def :event/event (spec2/multi-spec event-type :event/type))
;;  ⇒ works as expected

(spec2/def :event/event (spec2/multi-spec event-type (fn [val tag] (assoc val :event/type tag))))
;; throws no impl of conform* for PersistentList

;; test case
(gen/sample (spec2/gen :event/event))

Essentially looks like spec2 can't handle retag functions yet, which makes it impossible to spec anything beyond simple maps, sadly.

Problem with (s/nest) and (s/describe) in spec-alpha2

Tue, 20 Oct 2020 16:55:08 +0000

It looks like calling (s/describe) for (s/nest) specs fails with an exception.

The following call:

(s/describe (s/nest int?))

fails with this exception:

IllegalStateException Attempting to call unbound fn: #'clojure.core/unquote
    clojure.lang.Var$Unbound.throwArity (Var.java:45)
    clojure.alpha.spec.impl/nest-impl/reify--1676 (impl.clj:647)
    clojure.alpha.spec/form (spec.clj:258)
    clojure.alpha.spec/form (spec.clj:254)
    clojure.alpha.spec/describe (spec.clj:282)
    clojure.alpha.spec/describe (spec.clj:279)
    stem.i.log/eval16342 (log.clj:91)
    stem.i.log/eval16342 (log.clj:91)
    clojure.lang.Compiler.eval (Compiler.java:7177)
    clojure.lang.Compiler.eval (Compiler.java:7132)
    clojure.core/eval (core.clj:3214)
    clojure.core.server/prepl/fn--8941 (server.clj:232)

in spec-alpha2 with the latest commit from master

{:git/url "https://github.com/clojure/spec-alpha2.git" :sha "d514b06b25c41a676b95afcc9bfac8ca34c5741e"}

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.

Is it possible to attach spec to the local variable (via meta maybe?)

Sat, 29 Aug 2020 07:03:24 +0000

Sometimes it may help a lot if you can quickly check the shape of the local data, after series of transformations for example.

Is it possible?

And is it possible to spec (some) steps of thread-first/thread-last for instance?

As a random idea, something like this?

(->> xs
     ^:xs (map ...) ;; <- attaching spec for output via tag
      (filter ...)
      (remove ...)

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?