Clojurians Log v2

@flowthing I would be curious of more people used set/different as (set/difference set non-set ....)

As KeySeqs are unique it feels a bit iffy to have to do (set/difference my-set (set (keys my-map)))

Here's a map of [function-name occurrences] => examples of args passed to that function: https://gist.github.com/eerohele/0dd0606213331c2dc5e3b8df2b21f352

Hope I didn't mess it up too bad... it's a pretty quick job.

Yeah, I agree. Need to look into that.

so 41 occurrences of difference with the arguments if I read that right?

Yes.

Seems like the (set/difference set non-set ....) pattern is pretty widely used

With arguments that don't adhere to the specs now in Speculative, that is.

Yep.

I suggest making the but-first args reducible-colls as here: https://github.com/slipset/speculative/blob/master/src/speculative/specs.cljc#L70

That can yield unexpected (non-set) return values.

@flowthing how?

I mean just for set/difference

Ah! I misunderstood. Yeah, that might work, need to look into it.

I’m looking at the offending calls to subset?. It seems only the second args has to be a set there. The first one is sufficient to be a seqable?.

union is disputable if that should accept non-sets.

according the :ret set? it’s wrong.

lastly, I don’t see any offending calls for other set functions. is that correct? only three.

Yeah, only three.

I think it's sort of back to the old question… should the specs allow everything that works (albeit coincidentally) or is it more logical to just allow sets. I don't know the answer, at least.

Summary : We discovered calls like: (set/difference set non-set) and (set/subset? non-set set). Both return sets in those cases. Coercion to set is unneeded. Not sure if users are relying on undefined behavior there or if we should account for it in the specs.

Maybe make an issue for it as the history of this chat will disappear after a while

I would love any info like this to be on the CLJ ticket you made

that should be the place to record all data that goes into “deciding what to do”

my main questions are: 1) what are the main error cases that a spec (or validation) could tell someone about early and 2) what are the existing non-set use cases that people rely on that we want to preserve if the code is changed

so that we can add value by detecting broken code and NOT break people’s existing non-broken code

That would be this issue, right? https://dev.clojure.org/jira/browse/CLJ-2433

yeah

There is definitely a blogpost if not a talk in this process that is speculative.

stuff that works should continue to work or (in our opinion) the spec is wrong

From its inception, mainly as a stubborn argument against you can’t contribute to Clojure without contributing to core. Through its development, where you Alex have shown interest and offered advice, to now where it’s somewhat helpful in the development of core (if you squint pretty hard)

you should account for it in specs

I am interested in reaching some conclusions on the set stuff and doing whatever that conclusion is in the next release (whether it’s specs, validation, coercion, etc)

if only so we can never speak of it again :)

:)

Some informal chit-chat: I’m sitting on a plane watching conj-videos on my way to London to speak at ClojureX. The future is now :)

All right, that's clear enough (and understandable, since it's in line with Clojure's don't-break-the-userspace policy). I'll check what that entails and modify the specs accordingly.

(By extension, I guess that means that the functions in clojure.set will never include assertions, either. So the only options are either coercion or something like clojure.set2.)

https://github.com/slipset/speculative/issues/161#issuecomment-443542942