This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-12
Channels
- # admin-announcements (2)
- # aleph (2)
- # arachne (16)
- # beginners (33)
- # boot (20)
- # bristol-clojurians (6)
- # capetown (4)
- # cider (50)
- # clojure (74)
- # clojure-austin (4)
- # clojure-canada (1)
- # clojure-china (2)
- # clojure-czech (1)
- # clojure-greece (1)
- # clojure-poland (4)
- # clojure-quebec (5)
- # clojure-russia (5)
- # clojure-spec (34)
- # clojure-uk (45)
- # clojurescript (131)
- # cursive (4)
- # datascript (2)
- # datomic (9)
- # editors (2)
- # emacs (2)
- # hoplon (173)
- # jobs (5)
- # lein-figwheel (3)
- # leiningen (1)
- # off-topic (1)
- # om (44)
- # onyx (8)
- # proton (10)
- # re-frame (81)
- # reagent (23)
- # untangled (57)
- # vim (2)
- # yada (8)
Can someone please comment on http://dev.clojure.org/jira/browse/CLJ-1966? I would like to know if I possibly understand something wrong.
I'm afraid I'm still failing to understand the difference between keys
and keys*
. I understand that only keys*
works in a cat
, but I don't understand why. Is this explained somewhere?
@akiel rich hasn't looked at it yet
@peeja keys is a spec for a map. keys* is a spec for a sequential list of alternating keys and vals
I'd say they work in different contexts to match the same thing :)
@alexmiller it’s ok, as long as it’s on your list - thanks
Revisiting the “spec strings as char seqs” idea from the weekend, I just threw this together:
Bad idea or simply misguided? 😛
@donaldball: from a spec perspective I think it's much better to use an actual regex for matching
The things I’m finding attractive about expressing specs on char seqs are that the spec regex forms are often more readable, but more to the point: you get working generators for free
There is a project for assembling readable regexes, can't remember the name
yeah, that one
and also test.chuck has support for generating strings based on a regex
When writing regex specs, is there a way to get at the bindings "so far"? For instance, say I want to validate a datom [e a v]
, where a
is keyword that represents a spec. I'd like to use that spec to validate v, and get "nice" output from explain
that the failing spec is the one represented by a
.
@dave.dixon custom predicate? (s/and <datom-spec> #(s/valid? (:a %) (:v %)))
doesn’t integrate into explain of course
@alexmiller: what is the thinking behind it being under consideration? What are the downsides of allowing docstrings on specs?
@alexmiller: would be nice if there were a way to pass explain results out of custom predicates. Though perhaps not required in most cases.
@danielcompton asking the wrong person :)
@dave.dixon: while it's tempting, I don't think Rich is inclined to support that for uniformity.