@gfredericks thanks for the example, instrument {:gen (f [] somegen)} works indeed

Before I post this to JIRA, could someone take a look if this is bug? https://gist.github.com/borkdude/95301951e81e3022674279d463783586

@borkdude reloaded.repl is not a valid symbol

@moxaj Why not - and why is this the only symbol in my dependencies causing problems?

(symbol? ’reloaded.repl) ;;=> true

According to https://clojure.org/reference/reader#_symbols it is valid I think?

yeah, I was wrong about that 😮 seems like a bug to me

if you move the quote inside the set it works

Ah

This also works:

user=> (def deps ’#{[org.clojure/core.async “0.3.442”]
    [prismatic/schema “1.1.4"]
    [com.stuartsierra/component “0.3.2”]
    [reloaded.repl “0.2.3"]})
#’user/deps
user=> (s/def ::dependency deps)

or the equivalent in a let, but not inside ->>. Probably because def and let are compiler level things and ->> is a macro

I can live with the let solution, but if it’s a bug, I’m happy to post it to JIRA

it’s not a bug

the quoted form is expanded to (quote #{ ... })

s/def is a macro - it doesn’t expect to find a (quote ...) form

@borkdude ^^

@alexmiller why is it trying to resolve the symbol though?

where do you see that?

I think this is the line throwing the exception: https://github.com/clojure/clojure/blob/master/src/clj/clojure/spec.clj#L308

oh, it’s seeing a bare symbol with a “.” in it, which is interpreted as a class instance

so it’s trying to load the class

reloaded.repl is being interpreted like java.lang.String

“it” here being the compiler, I don’t think it’s ever even getting to spec

@alexmiller to me it seems like the resolve call at the line I linked is responsible for the exception

or what do you mean by "not getting to spec"?

Then what’s the difference between calling

(-> '#{[org.clojure/core.async "0.3.442"]
    [prismatic/schema "1.1.4"]
    [com.stuartsierra/component "0.3.2"]
    [reloaded.repl "0.2.3"]})

(s/def ::dependencies '#{[org.clojure/core.async "0.3.442"]
    [prismatic/schema "1.1.4"]
    [com.stuartsierra/component "0.3.2"]
    [reloaded.repl "0.2.3"]})

both are macros

well the macros do do different things :)

@moxaj you could be right - it’s basically the point at which the form passed to s/def is evaluated inside s/def

s/def uses the form in both an evaluated and unevaluated context

https://gist.github.com/moxaj/d21f8f1db3e4cf32dcb12485a248070e

but I quoted the form which should remain the same when evaluated?

replaced resolve with my-resolve to confirm

during macro-expansion a quoted form is literally (quote ...) - it has not yet been evaluated

hmm ok

+1 on clojure.spec use data > functions > macros.... I also have some problems related to this macros...

the quote expansion happens during reading

@souenzzo several parts of spec don’t work without macros

like explain

also, keep in mind that spec forms are data and can be conformed into a map-y form with spec specs (and unformed back)

they can also be transformed in the middle of that or even constructed straight from the mappy form via unform

Not yet right?

ok, so in the case of passing a set, it’s best to evaluate it before passing, instead of quoting it

hard to say “best” - just that there is an interplay here between reading, macroexpansion, and the macro that is subtle

@borkdude in your case, the safest I believe would be to def it, and use the var

@mpenet patch is on CLJ-2112. it’s not done yet but idea is there.

@moxaj yes, let also works (wrote that earlier already)

Yes

(defn make-or [keys preds]
  (let [or-data {:s 'clojure.spec/or
                 :args (map #(hash-map :tag %1 :pred [:pred %2]) keys preds)}]
    (s/unform ::ss/or-form or-data)))
(make-or [:a :b] [`int? `keyword?])
;;=> (clojure.spec/or :a clojure.core/int? :b clojure.core/keyword?)

was just playing with it this morning actually - there’s a function that makes a spec from data

So "are" -> "will be"

well I’d say specs “are” data now, just that you need the specs for that data too

the ::ss/or-form in the example above is the only missing piece

Is there some way of specing a situation where a map has mutually exclusive optional keys? That is neither ::a or ::b is required but if ::a appears, ::b may not and vice versa.

You can and a predicate

Or possibly multi-spec is a better match

Can you explain what you mean by "and a predicate?"