I have a bunch of mx/defn improvements.

One I just thought of is, using catn instead of cat so [:=> [:cat :int :int] :int] could become [:=> [:catn [:a int] [:c int]] :int]

the ones I have right now, are :no-throw, :gen, :seed, and :size

I am calling mg/generate — but I think there’s a way to use -strument to do the generation

idk which is better

from the function schema doc:

(def pow-gen
  (m/-instrument
    {:schema [:function
              [:=> [:cat :int] [:int {:max 6}]]
              [:=> [:cat :int :int] [:int {:max 6}]]]
     :gen mg/generate}))

I guess with symbols, so:`[:=> [:catn ['a int] ['c int]] :int]`

symbols!! 😍

yeah, the name can be anything

no need to allow that unless people want it.

no such mappings yet. I have the schema-type -> type mapping in top of the backlog, e.g. int? is a :int. simplifies things like JSON Schema mappings would do it with (java/js) type hints too.

That is something that will be really good to have

search for :gen/gen from the README (requires a generator, not sure if plain function is valid here.

should there be :gen/fn :thinking_face:

@U04M0JEU88Z here's a little example of using a custom generator:

Thank you both for you replies. I have fortunately found clojure.core.inst? fn to be a better replacement for my case. Still not sure how to fix my previous trouble, but the answer can be probably found by studing clojure.test.check.generators and than using :gen/gen .

if that is all for a single POST, It’s a lot. There are two good ways to organize schemas: 1. Vars a. like plumatic, (def NewFoo (m/schema …)) b. simple, usually non-qualified keys 2. Global Registry a. like spec, description here: https://github.com/metosin/malli#mutable-registry b. mutable = evil, qualified keys. for serving requests over web, the boilerplate of dealing with optimized encoders & decoders can be pushed into frameworks, e.g. reitit + malli here: https://github.com/metosin/reitit/blob/master/examples/ring-malli-swagger/src/example/server.clj#L57-L81. btw, nowadays malli caches automatically validators, explainers and generators but NOT transformers. so this is almost as fast as manually creating a validator:

(def Foo (m/schema [:map [:x :int]]))

;; caches the validator on first invocation into schema instance
(m/validate Foo {:x 1})

> nowadays malli caches automatically validators, explainers and generators Really? That's great news. > can be pushed into frameworks that's what our json schema is meant to handle, but switching over entirely to malli is long and hard and there's no desire to move off of compojure, so right now i'm stuck carving out a small corner of sanity in the much larger code base.

> • private post-foo-decoder which is standalone to get speed from m/decoder > • decode-foo-params that uses post-foo-decoder to decode the payload I've usually created closed over functions that internally create the decoder.

(def decode-foo-params [..] (let [decoder (..)] (fn [..] (decoder ...))

I've also created orchestration functions that deal with the repetitions of an operation (and you can more declaratively just pass in a map of {:my-schema ,, :post-decoder-fn ,,, :etc})

Arne also had a talk about data-driven malli which I think can serve as inspiration on how to generate more of this stuff based on some initial schemas. https://www.youtube.com/watch?v=ww9yR_rbgQs

very cool, thanks for the talk. watching it now

If you care about performance then you should consider dropping compojure, otherwise you can borrow the coercion middlewares from reitit

hah I would love to drop compojure. getting organizational buy-in is quite challenging, sadly

no simple built-in for that, but:

(defn my-named-args-fn [& {:keys [x y z]}]
  (println x y z))

(malli.destructure/infer #'my-named-args-fn)
;[:=>
; [:cat
;  [:altn
;   [:map [:map
;          [:x {:optional true} :any]
;          [:y {:optional true} :any]
;          [:z {:optional true} :any]]]
;   [:args [:* [:alt 
;               [:cat [:= :x] :any]
;               [:cat [:= :y] :any]
;               [:cat [:= :z] :any] [:cat :any :any]]]]]]
; :any]

should that be an :or? maybe I don't remember how that destructuring works

to add, if you use mx/defn on that shape, the destructuring schema will be inferred. ( I think ).

yea.

(require '[malli.experimental :as mx])

(mx/defn my-named-args-fn [& {:keys [x y z]}]
  (println x y z))

(:schema (meta #'my-named-args-fn))

;; => [:=>
;; =>  [:cat
;; =>   [:altn
;; =>    [:map
;; =>     [:map
;; =>      [:x {:optional true} :any]
;; =>      [:y {:optional true} :any]
;; =>      [:z {:optional true} :any]]]
;; =>    [:args
;; =>     [:* [:alt
;; =>          [:cat [:= :x] :any]
;; =>          [:cat [:= :y] :any]
;; =>          [:cat [:= :z] :any] [:cat :any :any]]]]]]
;; =>  :any]

you could have a function that return that shape ^

@UEENNMX0T :alt & :altn are the or for sequences. That should work ok.

btw, like with mostly everything else in malli, you can configure the dest inferring with options, “closed map with required keys”:

(md/infer #'my-named-args-fn {::md/closed-maps true, ::md/required-keys true})
;[:=>
; [:cat
;  [:altn
;   [:map [:map {:closed true}
;          [:x :any]
;          [:y :any]
;          [:z :any]]]
;   [:args [:* [:alt
;               [:cat [:= :x] :any]
;               [:cat [:= :y] :any]
;               [:cat [:= :z] :any]]]]]]
; :any]

it would be easy to build a custom schema to cover the both cases (map or varargs), e.g.:

[:=>
 [:cat
  [:kvmap
   [:x :any]
   [:y :any]
   [:z :any]]]
 :any]

Thanks a lot. I will play with that and would like to create a fn to simplify the declaration.

@U055NJ5CC I don't see anything about this in the 0.9 changelog. Should I whip up a full repro? I'd thought there were others doing this, but maybe I'm the only one?

there should not be any breakage. Please create an issue with minimal repro.

works here ok :thinking_face:

(ns demo)

(defn plus
  "adds two numbers together"
  {:malli/schema [:=> [:cat :int :int] :int]}
  [z y]
  (+ z y))

(require '[malli.instrument])
(malli.instrument/collect! {:ns 'demo})
;#{{:clj {demo {plus {:schema [:=> [:cat :int :int] :int]
;                     :ns demo, :name plus}}}}}

For what it's worth: I'm having the same problem. Did you find out what was the matter @U01R1SXCAUX?

To be clear: • (mi/collect!) does not work • (mi/collect! {:ns 'demo}) does Upon closer inspection, the 0-arity call defaults to using *ns* as namespace. In my case its value was different from what I expected during my REPL session. Maybe the same for you Michael.

Ugh, that doesn't look right. Not using the 0-arity, it's clearly broken.

Issue welcome, should be easy to fix

https://github.com/metosin/malli/issues/834

fixed in master.

thank you!

rendering schemas + also schema editors would be awesome.

Thank you @U055NJ5CC

yes, that works if you rely on global options.