Fork me on GitHub
#clojure-spec
<
2017-08-24
>
jpmonettas15:08:53

hi everybody, what's the way to spec something is a promise of some kind

Alex Miller (Clojure team)15:08:50

not really any good way right now

Alex Miller (Clojure team)15:08:30

I would focus on spec’ing the place where you deliver the value and receive the value

joshjones15:08:32

you could do

(s/def ::promise #(= (class %) (class (promise))))
?

joshjones15:08:38

you could put the class of the promise elsewhere if you wanted to avoid creating a promise each time you ran the predicate

Alex Miller (Clojure team)15:08:40

I’m not sure there’s much value in checking just that something is a promise. I presume what is of interest is that it’s a promise that returns something that matches a spec

Alex Miller (Clojure team)15:08:59

however, checking for that would require you to block waiting for the promise to be delivered

Alex Miller (Clojure team)15:08:33

so I think you instead want to validate the spec at the point where you are already retrieving the value

Alex Miller (Clojure team)15:08:44

or where you are delivering the value

jpmonettas16:08:47

yeah I'm trying to spec a function return that returns a promise with an int?

jpmonettas16:08:08

since it's a :ret I'm not worried about instrument blocking on deref

jpmonettas16:08:44

I'm more interested in the doc aspect

seancorfield16:08:27

Several times I've wanted to be able to spec "this should be an atom containing an X" so I feel the lack @jpmonettas -- but as @alexmiller says, a lot of the times where you would want this, spec would need to deref the container to check the value inside and that's not the correct semantics (it would block).

Alex Miller (Clojure team)17:08:35

No, that's different. Atom deref is not blocking

Alex Miller (Clojure team)17:08:11

We might add atom-of eventually

seancorfield17:08:48

I meant more in the general "derefable" situation -- but you're right that each type of derefable is different.

Alex Miller (Clojure team)17:08:12

All of the Clojure reference types do nonblocking read

seancorfield17:08:12

Good point. Future/Promise are the outliers.

Alex Miller (Clojure team)17:08:45

none of Future/Promise/delay are reference types

Alex Miller (Clojure team)17:08:28

that is, by “reference type” I mean, IRef (not IDeref)

seancorfield16:08:24

It would make me want to have the function return int, and instead call it in a future (which has the advantage that the caller controls both the wrapping and the dereference).

seancorfield16:08:49

(since you don't mind the checker blocking on a deref to check the value anyway)

mpenet16:08:32

You can put a validator on the atom with a valid? check i guess

mpenet16:08:44

Wont help with gen tho

mpenet16:08:46

Golang is interesting for chan args, you can say "this arg is a chan of int that can only be take!en in that scope" etc

mpenet17:08:25

Chan args have a concept of "direction"

Alex Miller (Clojure team)17:08:01

As do core.async chans via the port protocols

mpenet17:08:18

Yes it s very similar

mpenet17:08:11

xforms on chans might make specing them more tricky tho