Fork me on GitHub

i wonder why aren't specs first class things we can define literally and pass around, and why they need their own special registry when we already have namespaces and vars? :thinking_face: i'm playing with building up specs in an automated way (e.g. reducing a data structure into a spec representation). looks like i'm gonna have to s/def things along the way. isn't that some kind of PLOP? maybe this is something that will be improved in future version 😄


The latter it seems


Why another registry, I believe to not clutter vars/nses more and make their potential evolution separate?


then why not have a registry for all atoms? and another for all fns? and on and on. 😂


There are already issues with vars initialization at startup right now, I guess that's not to make it worse among other thing. Then it's a "private" thing, we never get exposed to the fact it's separate


i see. 😞


We ll see with alpha2 I guess. The posts from @alexmiller about the ongoing work on this are quite interesting

👍 5

they don't reveal much about these 2 questions in particular, but soon enough it might


@devth if you can give an example, we can see if it can be improved using the current version of spec?


@devth there is s/spec which gives you spec w/o being registered, which might be useful for you if you build specs dynamically, use, and throw away right away.

Alex Miller (Clojure team)13:01:31

there are no plans to change the registry aspect of spec

Alex Miller (Clojure team)13:01:42

all of the programmatic construction aspects will be different in spec 2


@alexmiller could you elaborate more on that? Will existing dynamic specs break?


Does there exist a flavor of s/merge for disjunctions, i.e. s/or? I have a base set of disjunctions (A or B) that I’d like to be able to extend in certain contexts (base or C or D).


@devth Isn’t this the flaw of current spec that Rich spoke about in his recent Clojure Conj talk?


i'm not sure i've seen his latest conj talk. i'll have to look it up


oh, i have seen part of that one.


still curious about the place vs value oriented nature of spec :thinking_face: any thoughts?


I recommend watching the talk.


k, i'm 30 min in. still watching 🙂


let it sink in on the hammock 😉

🤯 5

taking notes


Big ideas: 1. separating out schema (shape) and selection (optionality). cool stuff! - it's still not "just data". why the departure? everything in Clojure is just data, and for good reason. the entire core lib is built around manipulating data. it's the best part of clj. - it's still place oriented, at least from what i gather so far 😞 2. Better programmatic manipulation of specs. great! but again: why not make it data? then programmatic manipulation comes with. Imagine if the schema for:

{:weather {:weatherbitio {:key "xoxb" :default {:zip "98104"}}}
   :command {:prefix "!"}}
Was simply:
{:weather {:weatherbitio {:key string? :default {:zip string?}}}
   :command {:prefix string?}}
There's elegance in mirroring the data structure you're specifying, kinda like how Datomic Pull queries mirror the data you get get back. :thinking_face:


or do you mean “why do I have to gives names to each sub-spec, can’t you inline them?” ?


it may be related to each other


yeah, both i think. i want values


future spec will allow you (I think!) to spec the whole schema and then define selections on them, so you don’t have to name each selection.


I’m not entirely sure if this maps to your issue with spec, but just my 2cts


pretty sure that'd help!


any word on timeline for the next version of spec?


Whenever I’ve seen this asked, the short answer is “when it’s ready” 🙂


haha. fair

Alex Miller (Clojure team)16:01:57

I’m working on it every day

Alex Miller (Clojure team)16:01:13

hard to say when the next point will be where it’s useful to look at but it won’t be “a” next version - it’s going to be a series of releases


so to be clear: currently there isn't necessarily a better way to achieve what i'm doing? i have to dynamically s/def a bunch of stuff?


@devth there is a lib called spec-tools which may help you accomplish this, but I expect breaking changes when new spec comes out


I haven’t used it in anger myself


looks interesting, thanks.


you may lose the ability to generate data this way, I’m not sure


@devth o wait, maybe it was this: (the README is so long ;))


> Just data, no macros 💯


long READMEs are nice 🙂

Alex Miller (Clojure team)17:01:11

most of things spec-tools is built on are going away, but there will be one or maybe even two alternative paths to this goal


I’m not sure if I agree. Do one thing well also has benefits 🙂


not familiar enough with spec-tools to have an opinion on whether it should have been multiple libs. but long searchable READMEs with lots of examples are always nice.


i think i'll play with spec-tools for now. if things change i can always port to the new way


glad I could help 😛

👍 5

(create-ns 'my.really.long.ns)
(alias 'mrln 'my.really.long.ns)

Is this trick for shorter namespaced keywords likely to get me scolded by experienced clojure spec devs? Is it better to formally create the ns file even if it’s largely empty?


@cjsauer there is something like this in spec itself, so I think it’s ok


@cjsauer if you’re writing portable code, be aware that this may not work on CLJS


@cjsauer I tried moving this to a proper ns, so CLJS could use the alias as a namespaced keyword as well, but that was rejected:


Ah interesting, thank you. in-ns is a bit better. Which part of this does cljs not like? I am hoping to use these specs on both server and client.


@cjsauer in-ns simply doesn’t work in CLJS.


it does, but only in the REPL.


Bummer…does the same go for create-ns?


(I think so, gonna check now)


(ns dude)

(in-ns 'foo)

(defn foo [x])

(in-ns 'dude)

(defn dude [x])

$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.439"} org.clojure/test.check {:mvn/version "RELEASE"}}}' -m cljs.main -t node -c dude
WARNING: dude is a single segment namespace at line 1 /private/tmp/repro/src/dude.cljs
WARNING: Use of undeclared Var dude/in-ns at line 3 /private/tmp/repro/src/dude.cljs
WARNING: Use of undeclared Var dude/in-ns at line 7 /private/tmp/repro/src/dude.cljs


Shoot…so then portable code will have to use the qualified keyword everywhere at the moment?


the fully qualified one yes


I may actually fall back to formally creating the namespace file for now, even if its mostly empty. Keyword fatigue is real…


it’s not a huge pain. you could make a function that creates the keyword if you want to save characters


@cjsauer we also have that in the app I’m working one, several almost empty ns-es for this…


Once CLJ-2123 is patched, I imagine it should be quick work to refactor


cool. hopefully CLJS gets this too


What is the philosophy behind spec’ing attributes that are intended to be used as references to other entities? For example, I might have ::company/employees which models a one-to-many relationship. How would I spec this attribute? My intuition is to use something like (s/coll-of ::employee), but the issue here is that I now have to define some minimum key-set that is ::employee, which is a spec that I think is largely contextual. Further, there may be contexts where (s/coll-of (s/tuple #{::employee/uuid} ::employee/uuid)) are valid ::company/employees, e.g. datomic idents. Ultimately what I think I’m wondering is: can reference attributes only be spec’d within a given context, or at specific boundaries (e.g. fdef)?


I think my confusion stems from the fact that a :db.valueType/ref attribute can take on lots of different forms throughout an application, and so it’s difficult to spec. For example, it could be a raw entity id, a {:db/id 000} map, a [:db/id 000] ident, some kind of custom [:employee/uuid #uuid "000"] ident, or it could be a fully formed employee map…all these can values live under the same ref attribute at one time or another.


I think only spec-ing the pull form (ie what you would get from a pull)


Those other variants are all part of the Tx map DSL


This just shifts the problem around though


I think the TX spec would only spec the coll not the keys individually


>I think only spec-ing the pull form (ie what you would get from a pull) I’ve been playing with a similar strategy. This way you can still make good use of generators without the concept of a database getting involved.


>I think the TX spec would only spec the coll not the keys individually @favila by this do you mean something like (s/coll-of (s/keys))?


Coll-of whatever a tx is


Coll of either Vecs with entity ref (= 2-tuple, long, or keyword) first item (Tx fns and raw add/retract) or tx maps; which are maps with entity ref keys and Tx map or col-of-txmap or entity ref or non-ref value or coll of non-ref value)


So pretty open...


In my tx function fdefs I’ve been specifying the :ret much more tightly. I’m less interested in spec’ing the :ret of any tx function, and more interested in spec’ing this specific tx function.


I’ve been staring at the code more, and I think what’s troubling is that when I want to specify the form of some ref attribute in general, it can’t really be done…the question of when is inescapable so to speak. Because if I specify the pull form for all of my ref attributes, now I’ve bound the keyword :company/employees to one specific context: the fully realized one. I can’t use the name :company/employees in other contexts in which it might make sense, because spec has already registered the “one true form”. Does this make sense, or am I complicating the issue? :thinking_face:


For example, a tx function might return a collection that includes a map with the :company/employees keyword in it, but it may not conform to the pull form. It may be a collection of idents instead, meaning it references pre-existing entities.


Because I’ve already spec’d it to conform to the pull form, I can’t use that keyword again in a new context…


Assuming it's a map using s/keys, you could make everything optional


I had the same idea, and it works okay. I think the downside is that it forces you to resort to custom generators pretty much everywhere…


But this is the exact problem Rich stated in his last conj keynote Maybe Not


There's not a great solution for it in spec


>But this is the exact problem Rich stated in his last conj keynote Maybe Not I think so as well. Pretty much anywhere that a map has to be specified, this problem will arrive. The concept of “entity” is still difficult to grasp in my opinion. “Entity” doesn’t seem to become concrete until some data arrives at a boundary/function.


@cjsauer you are exactly right about the problem


I don't think this is the same problem Rich has acknowledged


spec has a strong opinion that the keyword of a map is (essentially) describing the type of its contents


but there are cases where that is not true and the keyword is really a structure rather than a type tag


one is DSLs: e.g. tx map dsl, or even the pull expression dsl


in those cases the key of the map is a structural tag, not a type tag


and foreign system's data routinely make their map entries contextual to the type of thing they are in


both these use cases I have found are bad fits for spec; the only workaround is predicates


or more keys and lots of key renaming


"structural tag" is wrong


what I mean is they are like structurally-expressed arguments to some function call implied by the dsl


{:my/attr [:db/id :db/ident]} is not expressing a :my/attr value, it's telling you to do something to a :my/attr value in some different context


they can't be interpreted apart


so it's the type of the entry itself that matters rather than the type of the value


so, maybe multi-spec on the key as the dispatch value is getting towards the right answer?


>I don’t think this is the same problem Rich has acknowledged @favila I’ve just rewatched Maybe Not, and I think you’re right, it’s not the same issue. It is exactly the type/structural conflation that you’ve identified.


if anything, rich is moving even further away from keywords having any contextual meaning


s/keys at least let you attach predicates to the whole


He actually also mentions that :ret in function specs is starting to smell, and it’s in those :ret specs that I encountered this issue. So that may be telling…


If I ease up on trying to “nail everything down” with specs, as Rich puts it, it may alleviate some of these limitations


What did he say about ret specs again?


He touches on it at around this point in the video:


what he’s saying there is that ret specs don’t tell you much, you almost always want fn specs. so he wants to refine fn specs (make them easier to use?)


True…I think the root of it is definitely this “contextual keys” idea (keywords have different specs in different contexts). What might be cool is the ability to define a “disjunctive schema”:

(s/def ::widget (s/or* :A string? :B pos-int?))
and then use a function similar to Rich’s proposed s/select function in order to mask the contextually relevant predicates, e.g. (s/select* ::widget [:A]) would mean “in this context, only condition :A can match (anything other than a string would result in error)“.


Almost reminds me of tools.deps’ alias flag clojure -A:a:b:c