Fork me on GitHub

@fnil, it's always been this way...


finally starting to get a hang of how to use instrument effectively while doing interactive development via the REPL, :replace is very handy in isolating parts of a long pipeline of functions that build up the computation step by step


having a version of enumerate-namespace that recursively enumerates all the internal functions called by some top-level function would be quite handy


not sure if that already exists in some library, if anyone knows let me know


@ghadi @joshjones You are correct and I am embarrassed 😄 I think the case at hand may have contributed to the confusion. I was applying specs to a deep, previously unspec:ed map where both spec:ed and unspec:ed keys were present.


i'm converting the json schema for AWS cloudformation to clojure.spec


this schema has a few reflexive references


i'm running into problems when converting it to spec


i have a spec of form (s/def :foo/bar ...) where :foo/bar is used somewhere in the ...


this gives me an Unable to resolve spec error, what's the recommended way to do such circular definitions in spec?


Oh, I would love to have some sanity brought on to cloudformations json. Love the service but I stumble on the JSON details all the time


How is :foo/bar used recursively? Doesn't something like:

(s/def :foo/bar (s/keys :opt [:foo/bar]))
(s/valid? :foo/bar {:foo/bar {:foo/bar {}}})
work? Or am I being naive?


that seems to work in the repl


@chrisblom What @fnil has suggested works for a map. A more fleshed out example:

(s/def ::k string?)
(s/def ::m (s/keys :req [::k] :opt [::m]))
(s/valid? ::m {::k "abc" ::z 42
               ::m {::k "def"
                    ::m {::k "ghi"}}})


but I don't know if you're spec-ing a map, a collection, or what ? you can also do recursive definitions for collections, etc., but if you can be more specific about the structure you're trying to spec..


hmm thanks guys, it's working now, not sure what i was doing wrong


Hello. I think that fully namespaced keywords without full application's namespace should be considered as very bad practice (:message/state for example) at least in library code. But why the official guide is full of such usages?

(s/def :event/type keyword?)
(s/def :event/timestamp int?)
(s/def :search/url string?)
(s/def :error/message string?)
(s/def :error/code int?)


@prepor Why do you think so?


I think I agree @prepor. since specs are global I would say that libraries should never use keys outside of the namespaces already in the lib


to prevent clashes with application code and other libs


I think it makes it a tad harder to find the namespace where the s/def lives. Also, if you're referring to the specs in other namespaces, it's harder to figure out which namespace you need to require in order to have those specs available


@fnil because of @joost-diepenmaat explanation, yes


All true, although I find the flexibility great.


I’m using single-keyword namespaces in an application right now and it’s very neat. Writing libraries generally means sacrificing some easyness for interoperability


I definitely agree that it can be hard to locate where a certain keyword was defined (or sometimes redefined)


@joost-diepenmaat a boundary between application and library is often not clear. today it's application code, and tomorrow you can decide to split it into libraries to use inside your microservices.


so, personally I decided to not use "short namespaces" at all. and for me it's strange that official guide forces this usage. maybe I don't understand something...


The guide uses ::stuff in most places tho` which is qualified by the full namespace. I think the other places in the guide are just examples -- certainly not "forcing" any particular usage on you.


The spec guide seems to be aimed at learning how spec works, and as such, brevity and simplicity are key -- adding too much info on namespaces makes it more difficult to learn. ::mykey is short, and simple ... at any rate, if you want to do something like this, I think it's a good way to shorten the code while still being namespace-safe:

(create-ns '
(alias 'event '
(s/def ::event/type keyword?)


When something is used in guide without red warnings — it's "forcing" )


@joshjones yes, I know about create-ns / alias


It's a guide not a set of rules. You're reading too much into it.


If anything I'd say the core team don't provide enough guidance. They really don't force their views on anyone.


@seancorfield will you think the same when you catch a bug because two of your dependencies have name conflicts without any warnings because the official guide guided their authors to not always use fully qualified keywords? 🙂


It's near the only way how you can broke others code in clojure ecosystem in non tricky way, I think


When the core team talk about spec, they're pretty clear about using namespaces to prevent exactly that bug. Again, you're treating a learning guide as a rule book. There doesn't seem much point in this discussion if you're set on blaming the core team for your mistakes 😸


hm. wrong tools force me to make my mistakes. is there no chance that core team did something wrong? don't think so. I'm sure that its ok, then somebody asks questions about core team decisions.


I'm trying to find some big real world applications on github which uses core.spec but can't 🙂


One option I have found that can work is using the form can help work around circular dependencies.


@prepor We use spec in production fairly heavily — and I know there are other companies already doing so — but of course you won’t find commercial application code on GitHub 🙂


@prepor And remember the saying: “It’s a poor craftsman that blames his tools.” (not sure whether that saying originates but I remember hearing it a lot growing up)


can you spec a variadic function?


Sure. You use the regex specs to do so.


You can do something like:

(s/fdef hello
  :args (s/cat (s/? string?))
  :ret string?)

(defn hello
  ([] (hello “world”))
  ([name] (str “Hello, “ name \!)))


ok... I haven't looked into this much but wondering about doing pattern matching with core.match and spec to be like a guard or something...

Alex Miller (Clojure team)19:02:06

@prepor the guide uses shorter names and :: kws for readability. it would be reasonable to add a side bar explaining this.


@alexmiller cool, thank you! the only thing which I imagine to catch (and debug) such errors automatically is "production mode" for clojure.spec which forbids redefinition of specs in explicit way


@fnil we generate cloudformation templates as EDN and serialize to JSON, works great


@chrisblom that sounds like a great project. huge surface area, though


@spieden very cool! I have had such a thought but have not fully grasped cloudformation and its template language yet


it’s a bit of a curve but has been a great workhorse for us


can’t imagine maintaining a template by hand, though


we have lots of functions that build up common structures, etc.


without DRYing things out like this it’d be crazy town


Spec should be great for it


yeah for sure. they have their own (hosted) validation operation, but it misses things and works against the JSON representation


So I noticed 😄


Could you help a Newbie: I am going through and cannot get past

codebreaker=> (s/exercise (:args (s/get-spec `score)))

FileNotFoundException Could not locate clojure/test/check/generators__init.class or clojure/test/check/generators.clj on classpath.  clojure.lang.RT.load ( 
I am using Clojure 1.9.0-alpha14 in lein repl


add [org.clojure/test.check "0.9.0"] to your (dev) dependencies