Fork me on GitHub

Is it possible to spec multi arity functions with the experimental Plumatic-style schema?



(mx/defn plus
  ([x :- :int] x)
  ([x :- :int, y :- :int] (+ x y))
  ([x :- :int, y :- :int, & zs :- [:* :int]] (apply + x y zs)))


Doh, naturally, thank you.


My head was not screwed on right yesterday. What I meant to ask was, how do I scope a particular return spec to a particular arity. In e.g. Snoop, this is possible since the return spec is part of the arity. In Plumatic, I'm unsure what the syntax is.


there is no such thing in the Plumatic Syntax. Thought of adding that after the args-vector, but then it would not be Plumatic Syntax anymore.


I propose to ask this from the plumatic schema gang via an issue, happy to incorporate whatever they think is good, could add my 2 cents in the conversation there


… and you can do that with non-plumatic syntax already.


(defn f1
  (^{:malli/schema [:=> [:cat :int] :int]} [x] (inc x))
  (^{:malli/schema [:=> [:cat :int :int] :int]} [x y] (+ x y)))
(defn f2
  {:malli/schema [:function
                  [:=> [:cat :int] :int]
                  [:=> [:cat :int :int] :int]]}
  ([x] (inc x))
  ([x y] (+ x y)))

👍 1

I think it would be good to alias the Plumatic macro name to something like >defn as well. Partly because it seems to be a bit of a convention, partly because it makes it possible to refer it without breaking the equivalent in clojure.core.


Regarding arity-specific return specs; to me it makes sense to tack them on to the param vectors. It might even be possible to combine the two: a spec that runs regardless of the arity, and a spec that runs per arity.


Personally, I really don’t like the >defns. clojure.test is the only ns that I require macros without namespace alias. mx/defn tells where it is coming from.


(mx/defn plus :- :int ;; the default, masked by 2 arities? 
  ([x :- :int] :- :int x)
  ([x :- :int, y :- :int] (+ x y))
  ([x :- :int, y :- :int, & zs :- [:* :int]] :- :int (apply + x y zs)))


starting to be quite verbose. Have asked if Cursive could grey out the schema hints so it would be move visbile


> Personally, I really don’t like the >defns Fair enough. I tend to lean towards referring, when it's canonical or conventional (we decide on one >defn, and overloading it is an error), and >defn has become something of a naming convention among function spec libraries. > verbose Agreed, and it's also not that easy to make a formatter understand the syntax to begin with. The separate vector approach of Snoop/Guardrails etc. has the advantage of registering as a conventional function in terms of arguments fed to it. By contrast, Plumatic seems like it requires quite a bit of interpretation of syntax, especially when extended in this way. It also has advantages, of course.