This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-23
Channels
- # alda (1)
- # beginners (26)
- # boot (88)
- # carry (2)
- # cider (6)
- # clara (6)
- # cljs-dev (43)
- # cljsrn (14)
- # clojure (48)
- # clojure-belgium (2)
- # clojure-czech (4)
- # clojure-dev (1)
- # clojure-dusseldorf (7)
- # clojure-japan (1)
- # clojure-russia (55)
- # clojure-spec (65)
- # clojure-taiwan (1)
- # clojure-uk (28)
- # clojurescript (154)
- # cursive (5)
- # datomic (1)
- # editors (2)
- # emacs (29)
- # funcool (1)
- # jobs (3)
- # lambdaisland (5)
- # leiningen (1)
- # luminus (2)
- # new-channels (1)
- # off-topic (17)
- # om (18)
- # om-next (10)
- # onyx (24)
- # parinfer (14)
- # pedestal (4)
- # planck (3)
- # re-frame (69)
- # reactive (2)
- # reagent (3)
- # schema (2)
- # spacemacs (2)
- # sql (13)
- # vim (11)
@devn my problem is that i want to conform nested string data so i don't need to do it in two steps. it's possible to use conformer
but when there's a problem the error message is really, really bad (and there's nothing available in the public api for custom explanations). i'd like to simply write a custom spec against the protocols but alexmiller, in a previous discussion, has cautioned against that.
basically i'm at a crossroads where it's either write the data portion of the parser by hand, forgoing spec, or bend spec to do my bidding.
How do you spec a function with optional args that should be conformed to a map?
(defn foo
[& {::keys [bar]}]
;...
)
hmmm sounds interesting and actually useful @noprompt It might actually also help my use case
when an input param for example is a string but the string contains an elastic search query
This is a more concrete example:
(s/conform (s/and #(even? (count %))
(s/conformer (partial apply hash-map))
(s/keys :req [::foo]))
[::foo true])
There must be a better way of handling this for optional map args in fnshttp://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/keys*
@noprompt I will stick with my caution in trying to use spec regex to parse strings - that's not what it's designed for and I a normal regex is going to be a better choice. Why cant you use a regex predicate?
I put it in a set
yes, a set #{“foo”}
good day! is there a way to spec a function, which I expect to get as an argument? like "I expect function of 2 arguments: int and string"
also, something which I think is a bit not clear from the docs, fdef
adds an fspec to the registry under the fully qualified name of the function, so if you've written an fdef for foo
, you can use the symbol `foo in place of a spec
anyone know how to spec a map by predicates over its keys and values? really expected this to work:
(s/explain (s/+ (s/cat :foo string? :bar keyword?)) {"hi" :bye})
In: [0] val: ["hi" :bye] fails at: [:foo] predicate: string?
@bfabry thanks! ok, now just for academic interest:
(s/explain (s/+ (s/cat :foo string? :bar keyword?)) [["hi" :bye]])
a map is also I believe a sequence of tuples, not a single long sequence of key,val,key,val
yeah i guess i was expecting the regular expression to match multiple instances of [“hi” :bye] within the sequence
so this works
boot.user=> (s/explain (s/+ (s/spec (s/cat :foo string? :bar keyword?))) {"hi" :bye})
Success!
nil
as does this
boot.user=> (s/explain (s/+ (s/tuple string? keyword?)) {"hi" :bye})
Success!
nil
but like I said, the simplest way to spec it is
boot.user=> (s/explain (s/map-of string? keyword?) {"hi" :bye})
Success!
nil
@alexmiller i can't use regex in my case because the strings i'm parsing are context-free.
so use a parser like instaparse?
@alexmiller i probably would but unfortunately the story for clojurescript isn't solidified yet on that account.
@bfabry I would not use s/+
for that example above but (s/every (s/tuple string? keyword?))
- that’s basically (minus things like :kind
and :into
) what map-of
translates to
even still, the story for plugging into explainability with conformer
is just not good enough. yes, the result does tell what string is wrong but i'm not able to say where in the string something is wrong.
to be sure, i'm not complaining about spec. it's already saved me a huge amount of work. if i could tap into explainability it'd be a closed case for me.
not sure what to tell ya - you’re asking for things spec is unlikely to provide ¯\(ツ)/¯
because one of the ideas in spec is to make explainability generic
I haven’t talked with Rich about this specifically so this is just my read on it
when you get to a predicate the explanation is: the predicate failed
if you want more detail, make finer-grained predicates and combine them
if you want that + some sort of string parsing, I think you’re into the territory of custom specs
right, however, sometimes the context is a little more granular e.g. failure alone is not enough for reporting. sometimes there's additional context for why the predicate failed.
certainly not in alpha
I don’t have an answer on that
we can provide guidance when things move past alpha
chances are most folks won't be interested in implementing the protocols and will just use "stock" spec. a handful of people, like myself, would probably greatly appreciate and benefit from the protocols being stable.
doesn’t make any difference to me
I read both :)