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?

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

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.

there are no plans to change the registry aspect of spec

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

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

hard to say yet

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?

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?

I’m working on it every day

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

awesome

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.

@devth https://github.com/metosin/spec-tools#transforming-nested-specs applies to your situation I think

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

@devth o wait, maybe it was this: https://github.com/metosin/spec-tools#data-specs (the README is so long ;))

> Just data, no macros 💯

long READMEs are nice 🙂

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 😛

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

::mrln/attribute

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

https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/test/alpha.clj#L19

see also https://dev.clojure.org/jira/browse/CLJ-2123

@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: https://dev.clojure.org/jira/browse/CLJ-2421

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?

yes

(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

did that in CLJS: https://github.com/clojure/clojurescript/commit/731be5e0916ad8d619c302bfc9b985c4d10daa8d

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: https://youtu.be/YR5WdGrpoug?t=3174

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?))

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