Conceptually the same, clojure.spec.alpha itself uses that for keys* using &- https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L1810

I find it is often useful when chaining predicates. the main thing that makes it not useful most often are when you put something in it that gives you a conformed value that differs from the original (particularly s/or). I'd be curious what the most common cases are for you when it's an issue. in spec 2, there is a non-flowing s/and- (name subject to change)

I'll dig around in my code in a minute to see if I can find a succinct and reasonable example – my current project isn't so much a useful product as it is a playground to get a feel for what can be done with specs beyond simple validation, so most of the stuff in my immediate reach is kinda ramshackle and/or at the edges of what is intended. But yeah, s/or is the main culprit. Non-transforming conformations aren't an issue – if every spec in the chain simply returned its argument, s/and would be indistinguishable from its non-flowing variant.

But also, non-transforming conformations are less interesting. Conformation is one of the main things I'm trying to get a feel for right now. I found the Jira tickets where you discouraged one of the spec-tools maintainers from viewing specs as a coercion engine, so atm I'm trying to explore what kinds of transformations are supported, and how they can be used.

I think it’s likely that we will add a nonconforming or option - that’s the most common need. Mostly wondering if there’s anything else

> Conformation is one of the main things I'm trying to get a feel for right now. From various talks I've interpreted conformation being suggested in two places: • To make use of existing specs (like the keys* example conforms the tuples into a map for the existing keys spec). • In macros, where you're parsing at compile time for syntax reasons.

(I think those were probably talks by @U064X3EF3 so I'm sure he could say if those are accurate or not 😄)

> Mostly wondering if there’s anything else Probably not. Maybe alt, being the regex equivalent of the same. The other transformers don't really make things more deeply nested than they were before, so they're not usually an inconvenience. The case that prompted the question is a little unusual – I have a multi-spec in an and, so while there's a contract on what that multi-spec is supposed to represent, I can't necessarily be sure how it will conform (and since conformation output can be non-obvious I don't necessarily want to include that in the contract and count on it being obeyed). Easy solution in nonconforming, but it got me thinking that I may not rightly understand why and is designed the way it is and might not be using the tool in the best way.

the purpose of conforming is to tell you why and how a value matched a spec

> In macros, where you're parsing at compile time for syntax reasons. Parsing is kinda what I've been fixing on for my current understanding (not just macros, could also be for data-oriented APIs). It seemed like standard conformations all aimed to describe the implicit structure of their input while generally leaving the scalars at the leaves of the tree alone – exactly what a parser does with a stream of tokens, just here with potentially more initial structure than just a stream.

the "why" part is why s/or and s/alt tell you which path was taken, why s/cat separates it's concatenated parts, etc

s/and's flowing is extremely useful when chaining predicates (where typically the value is not not modified, just passed through) ala (s/and int? pos? even?)

How does that differ from how the non-flowing variant will behave? I thought conforming with a predicate function was essentially an identity operation, so here even? receives the same value that pos? did

https://insideclojure.org/2019/12/06/journal/

the original value (not the conformed value) is passed through s/and-

for specs that are pred fns, doesn't affect conform (but does affect gen)

Oh interesting. I'm not immediately seeing how it affects gen, could you say more on that?

it's explained in that blog

Ah sorry, skimmed poorly

well s/and- is - it only gens from the first predicate. s/and gens, then filters

I expect you will often need a custom generator with s/and-

Does this mean that and- will be an exception to the general rule that a spec's generator retries generation until it gets something that conforms to the (whole) spec? Or does and do some more proactive filtering ahead of that step with its 2nd through last terms?

I don't think it's an exception - they will all try 100 times and all spec generators check s/valid? on the generated values

s/and-, by not using anything but the original pred, is less likely to generate valid values though

Got it, that makes sense. I wasn't aware that the original flavor built its underlying pre-verification generator out of more than one of its terms

I'll have to read the implementation at some point, because it's not immediately obvious to me how that could even be done :thinking_face:

generate values from the first pred. only keep ones that satisfy 2nd pred. only keep those that satisfy 3rd pred, etc.

Just a chain of such-thats so the generation tooling handles filtering before the spec does its final check?

yes, so it helps to think about the ordering of preds in s/and

this is covered in https://clojure.org/guides/spec#_using_sand_generators

ack, my poor skimming embarrasses me again

I forgive you, there is a lot to read :)