Is there a preferred idiom for the use of 'world information' in predicates and specs? This can occur in data validation. To clarify some, you have a data value, which you can check the 'shape/type' of via predicate and spec involving that value. Once that checks OK, a further validation requirement would be to see if what the value represents exists (in a DB or directory or ...) and is 'properly configured'. Those checks require looking outside the value so a predicate doing these checks needs more than the value. Maybe that is access to an in memory cache or a DB key or whatever. I can think of several ways to do this, but they all feel a bit off. So, is there an idom / preferred way to have that information available in predicates and specs?

@jsa-aerial My gut feeling tells me that it’s not a great idea to do side effects in specs

specs are not a great match for these kinds of validations

in general, I've seen better success with dynamically generated static specs (like running some code to register a spec with a set of allowed values pulled from a db) than with dynamic specs (which somehow close over state required to dynamically check validity in some way)

I see - I can understand that. Basically this is 'out of scope'.

pushing the limits :)

might be easier to implement as an explicit validation implemented outside of spec

I will say there isn't any side effecting here, but it does use / need 'outside/ world' access

maybe something like this would work though:

(defn foo [conn]
  (let [vals (query conn)]
       spec (my-custom-spec vals)]
  (s/assert spec ...))

depending on how you use spec -- this won’t work for e.g. fdefs

Some other ways: augment the value first with the 'key' for outside data so that the 'value' is wrapped and contains the necessary information. That's not too bad. If you have a map, augment with the 'outside key' and explicitly check the map contents (as opposed to using spec'd keys). Again, not too bad but kind of not using spec idiomatically...

Rather worse: use a dynamic var to hold the outside 'key'... This actually feels a bit dirty.

it is

It's also worth mentioning that, strictly speaking, reading values from a DB is side-effecting because if you repeat the call, you will not necessarily get the same result. It's not mutating anything directly, but it is not a pure operation either. I think a lot of people tend to think that SELECT * FROM whatever is "readonly" and therefore not subject to side-effects...

(unless you're using Datomic where you can get the entire DB as an immutable value for whatever scope of request processing you want)

how do I write fdef args for a function that takes: [[a b] _]?

there are several ways to potentially spec "[a b]" - what have you tried?

could be an s/tuple, s/coll-of with :count 2, a nested s/cat

(s/cat (s/cat :a int? :b int? ) :_ any?)

nested regexes describe the same collection

wrap s/spec around the inner s/cat

to describe a nested regex collection inside the outer regex collection

(s/cat (s/spec (s/cat ...)))

not working 😞

@ag

user=> (s/valid? (s/cat :v (s/spec (s/cat :a int? :b int?))) [[1 2]])
true

ah okay… now I get it!

awesome! thank you @alexmiller and @borkdude!

in spec2 this will be called (s/nest ..)

apologies if this isn't the right place to ask - I've recently started using the replacement instrument function from jeaye/orchestra. I'm getting an error while generating one of my specs, the error is

Execution error - invalid arguments to orchestra.spec.test/spec-checking-fn$conform! at (test.cljc:115).
(\8 \9 \7 \9 \2 \5 \4 \2 \0 \1 \0 \8 \1 \6 \9 \3 \1 \7) - failed: string? at: [:args :digits]

er, one moment while i clean that formatting

I'm wondering if I'm missing something as I would expect to get a more detailed/specific error about what spec failed

whereas the error seems to be something internal to orchestra

@robertfrederickwarner That looks to me like it expected a string but was passed (seq s) -- i.e., a sequence of characters instead.

Yup - that's the problem within the spec. My confusion is more that the error from orchestra isn't what I'd expect to see - looking at https://github.com/jeaye/orchestra/blob/2019.02.06-1/src/clj/orchestra/spec/test.cljc @ line 115 (the line from the error above), I'd expect to see an error prefixed with "Call to..." followed by details about the spec that failed

The problem itself - passing a sequence of chars instead of a string - is occurring within a generator for a spec so I am wondering if that is causing problems for the usual reporting

I saw some discussion of orchestra here earlier so thought I would throw it out incase anyone here recognized something obvious, I'll dig around some more but may open a bug to see what @jeaye thinks

did some further digging and tried out the standard instrument. Orchestra was hiding the error location a little bit but otherwise returns similar to the standard error

@robertfrederickwarner So the issue exists in the upstream spec instrumentation as well?

The upstream error I got was

Execution error - invalid arguments to ws.data/luhn-check-digit at (data.clj:39).
(\8 \9 \2 \2 \5 \0 \7 \9 \2 \3 \9 \6 \4 \5 \3 \2 \6 \8) - failed: string? at: [:digits]

So at least that let me see the line in question (data.clj:39)

Ok, it's likely an issue with the way your spec is written then.

Will you show your code, or a minimal repro case?

sure, let me just strip out some specifics here