How would you spec the following: [:keyword1 '(:one :or) '(:more :lists) :keyword2 '(:one :or) '(:more :lists)] where each pair of :keywordN '(:one :or) '(:more :lists) is optional?

I tried:

(s/cat :keyword1-pair (s/?
                  (s/cat :keyword1 #{:keyword1}
                         :keyword1-lists (s/+ list?)))
         :keyword2-pair (s/?
                 (s/cat :keyword2 #{:keyword2}
                        :keyword2-lists (s/+ list?))))

Nevermind, it does work. I had a typo.

I have another question though. It seems that conform evaluates the forms?

Basically, my above spec is for a macro. And I expect the lists to be code forms. Then I call conform to get it conformed, but it seems to evaluate the forms.

(defmacro foo [& bar]
  (s/conform ::my-spec bar))

(foo [:keyword1 (+ 1 1)])

Ah yes, nevermind again

@alexmiller I'm trying the latest Spec2 and running into a new failure

(s/defop length-limited-string
  "Given n return a spec for a string that is less then n characters
  long."
  [n]
  (s/and string? #(>= n (count %)))) 
;=> #'ws.billing.specs/length-limited-string
(s/def :wsbilling/braintree-id (s/nilable (length-limited-string 64))) 
;=> :wsbilling/braintree-id
(s/def :wsbilling/risk-id :wsbilling/braintree-id)
;=> :wsbilling/risk-id
(s/get-spec :wsbilling/braintree-id)
;=> #object[clojure.spec_alpha2.impl$nilable_impl$reify__12249 0x689396e2 "clojure.spec_alpha2.impl$nilable_impl$reify__12249@689396e2"
(s/get-spec :wsbilling/risk-id)
;=> nil

If I change :wsbilling/risk-id to

(s/def :wsbilling/risk-id (s/spec :wsbilling/braintree-id))

Unfortunately we have a lot of specs that are defined as aliases of other specs. I happened to spot this one because we have a test that verifies every key in a related spec has a spec defined for it...

Ah, it looks like that spec exercises and conforms just fine, it's only get-spec that "fails" by returning nil.

OK, it looks like we used to call s/spec in these cases with Spec1, but that stopped working in Spec2 with the API split into symbolic specs and spec values, so I changed it to s/get-spec and checked it returned non-`nil`. But what I probably should have done was used s/form instead which seems to do the right thing in Spec2. It still seems surprising that s/get-spec returns nil for the case above tho'...

I know why you’re seeing that

Is it a bug or should I just not be doing it that way?

(I have almost everything passing again on Spec2 -- still trying to track down one failure in one of our newer apps)

OK, everything passes. The only change I had to make was that get-spec issue (in three places).

I'll take a break for a bit and then start looking at schema/`select`...