Fork me on GitHub
Ben Sless08:04:33

Is it by design that schema transformations like mu/assoc don't play well with an unregistered schema?


not by design, could you repro if there is something that doesn’t work?

Ben Sless09:04:27

(def Foo
   [:a int?]])

(mu/assoc Foo :b ::bar)
Minimal example


you should declare the ::bar so that is is visible, either: 1. override the default registry 2. pass the registry into Foo when creting it (it closes over the creation time registry) 3. pass the registry into mu/assoc

(def registry
  (merge (m/default-schemas) {::bar int?}))

(def Foo
     [:a int?]]
    {:registry registry}))

(mu/assoc Foo :b ::bar)
; [:a int?] 
; [:b :user/bar]]

(mu/assoc [:map [:a int?]] :b ::bar {:registry registry})
; [:a int?] 
; [:b :user/bar]]

Ben Sless09:04:57

I managed to get myself into this corner like so: • wanted content dependent schema • wanted to parametrize the schema (makes it extensible) • figured out I'd do it by delaying registry building and schema compilation to run-time. • With registry I need ::my-schema • Can't transform anything with ::my-schema at compile time I can create a placeholder registry for it but it seems like it would lead to errors down the line

Ben Sless09:04:40

I'd be happy to adopt a better idea


me too 🙂 spec partially checks the references eagerly, partially lazily (e.g. s/keys), malli is currently eager.


there is an internal escape hatch: :ref doesn’t check the reference if :malli.core/allow-invalid-refs option is truthy.


it is used with local registries, which can have… holes.


  [:schema {:registry {::foo [:ref ::bar]}} ;; incomplete registry
   [:tuple {:registry {::bar int?}}
    ::bar ::foo]]
  [1 2])
; => true


ideas welcome how to make this good.

Ben Sless10:04:25

I don't know if it's good, but perhaps a :delay or :defer schema, which delays registry lookup to validation, with ample warning, care, etc.

Ben Sless10:04:24

Perhaps even wrap it in a function which will always emit warnings when it's called, i.e.

(mu/assoc Foo :b (m/schema (m/defer ::bar)))
STDERR: Deferred Warning *at* - instances of deferred schema must be provided with a registry at run time!
You can also throw when instantiating an explainer, transformer, or validator from it, which is when you actually need the registry


could it be just [:ref {:lazy true} ::bar]?

Ben Sless10:04:40

Ah, laziness has to be explicit


oh, ref’s are lazy already :thinking_face:

Ben Sless10:04:15

yeah, this didn't work 🙂

Ben Sless10:04:20

we need lazier laziness


try (m/-lazy ::bar options)


refs resolve eager by default, but one can create lazy refs with that.


(let [-ref (or (and lazy (-memoize (fn [] (schema (mr/-schema (-registry options) ref) options))))
                      (if-let [s (mr/-schema (-registry options) ref)] (-memoize (fn [] (schema s options))))
                      (when-not allow-invalid-refs
                        (miu/-fail! ::invalid-ref {:type :ref, :ref ref})))

Ben Sless10:04:40

Cool, it worked 🙂

Ben Sless10:04:49

Always good to know some black magic


could make a version of that which doesn’t require the options.

Ben Sless10:04:35

It makes me wonder why [:ref {:lazy true} ::bar] didn't work


it’s a property of the IntoSchema, not Schema instance.


by design, all the IntoSchemas are crated using a function, which can take properties how the IntoSchema works. Easy to extend the system that way and DCE drops all the unneeded schemas.


for example, it’s reletively easy to create custom collection schema types:

(defn -collection-schema [{type :type fpred :pred, fempty :empty, fin :in :or {fin (fn [i _] i)} :as opts}] ...)


:ref has:

(defn -ref-schema
   (-ref-schema nil))
  ([{:keys [lazy type-properties] :as opts}] ...))


but, could lift the lazy into a :ref schema property too. so one can say [:ref {:lazy true} ::bar] as data.


if you need that, please write an issue.

Ben Sless10:04:10

I wonder if I should settle for m/-lazy

Ben Sless10:04:36

If I should consider functions prefixed with - as implementation detail, then I'd say that I shouldn't and open that issue


things starging with - are ok to use:

Ben Sless10:04:03

> might evolve during the alpha That's a risk I'm willing to take. I think if m/-lazy develops in any direction it won't be one which will have friction with what I'm trying to do, on the contrary. Thanks again for the help and guidance, you rock

Ben Sless09:04:09

Another issue I managed to stumble on, I defined a dependent schema like It works well but throws when I pass it to reitit routes when the coercion is compiled

Ben Sless09:04:20

Great, now I'm unable to reproduce it 😞


you should declare the ::bar so that is is visible, either: 1. override the default registry 2. pass the registry into Foo when creting it (it closes over the creation time registry) 3. pass the registry into mu/assoc

(def registry
  (merge (m/default-schemas) {::bar int?}))

(def Foo
     [:a int?]]
    {:registry registry}))

(mu/assoc Foo :b ::bar)
; [:a int?] 
; [:b :user/bar]]

(mu/assoc [:map [:a int?]] :b ::bar {:registry registry})
; [:a int?] 
; [:b :user/bar]]


Are there built-in functions to throw errors on invalid input? The plans for instrumentation in the above issue are nice, but I'm looking for something simple like spec/assert


You can always (assert (thingy-validator dada)) but the error is not so useful


Yeah, I wrote my own for now:

(defn malli-assert
  ([schema value]
   (malli-assert schema value ""))
  ([schema value msg]
   (when-not (malli/validate schema value)
     (throw (ex-info (clojure.string/join "/n"
                       (cons msg
                             (malli/explain schema value)))))
              {:value value})))))


Make a PR?


It's not ideal because humanize returns nested messages according to the path of the error, which I just flatten into a single string


Ok I'll submit an issue, just wanted to check if it was a design decision not to have an assert


Maybe AssertionError would be more appropriate :thinking_face:


And maybe use *assert* and make it a macro


Spec assert seems to use ex-info and a separate *assert* equivalent var


I have a follow up question from regarding emitting configuration for clj-kondo to pick up (which is an awesome feature by the way!). I have schematised the following code:

(m/=> hash-map-by
  [:=> [:catn [:f [:fn ifn?]] [:coll coll?]] map?])

(defn hash-map-by
  "Returns a map of the items in `coll` keyed by `f`."
  [f coll]
  (into {} (map (juxt f identity)) coll))
The function takes an arbitrary function, f, and a collection that will be converted into a map by applying f and identity to each item in the collection. Pretty standard stuff. 🙂 When I emit clj-kondo config with (mc/emit!), I get the following EDN:
{:lint-as #:malli.schema{defn schema.core/defn},
 :linters {:type-mismatch {:namespaces {example.hash-map {hash-map-by {:arities {2 {:args [:fn :coll], :ret :map}}}}}}}}
Please note, the 2-arity args say :fn and :coll returning a :map which means I get linting issues with something like (hash-map-by :user/id [{:user/id 1} {:user/id 2}]). Is this a bug worthy of a pull request or am I once again demonstrating my naivety? 🙈


currently there is no way to override per schema instance how the clj-kondo works, but would be easy to add. also, having an ifn? schema built-in, it could have the correct clj-kondo type. interested in a PR?


for the latter that is.


for the first, for the second, something like:


[:fn {:clj-kondo/type :ifn} ifn?]


I'm very interested in implementing this as we'd need it to complete the replacement of clojure.spec with Malli in our codebase, I think.


I can create a PR for sure. 💯


@U055NJ5CC can I just clarify what you're thinking in terms of a PR, please? I can add #'ifn? to the predicate-schemas and then these tests pass:

(testing "ifn schemas"
    (let [schema (m/schema ifn?)]
      (is (true? (m/validate schema (fn []))))
      (is (true? (m/validate schema (constantly 1))))
      (is (true? (m/validate schema :keyword)))
      (is (true? (m/validate schema (reify clojure.lang.IFn
                                      (invoke [_] "Invoked!")))))))
Is that what you had in mind when you mentioned having an ifn? schema built in?


yes, but also mappings for transformers, generators, json-schema, humanized errors and clj-kondo.


I'll take a look at implementing the full feature set for the ifn? domain. 👍


I'll not implement proper generation of interesting functions. Don't want to put us all out of a job. 😉


Oh, I think I see what you mean. You want ifn? to be parameterised so you can schematize the args and return values…?


So in the schema generator you can do something more than this:

(defmethod -schema-generator 'ifn? [_ _] (gen/return ::ifn))


I'd need to generate a function that returns valid data given valid arguments.


really, why?


there is already :=> and :function which have proper input & output generators


Because I thought that was what you wanted. 🙂


I think I misunderstood.


no, just the simple thing, lke fn? but bit different 🙂


If ifn? can remain a simple predicate, I should be able to have a first pass at a PR before the lunchtime walk. 🙂


One pull request with my stab at adding ifn? to Malli's list of supported predicates. Gotta go for a lunchtime stroll with the pup; I'll check in when I'm back in about an hour. 🙇