Clojurians Log v2

@mfikes Should the spec of the arg to into be ::ss/seqable or ::ss/reducible-coll? I’m always wondering about this myself when writing new specs. https://github.com/slipset/speculative/pull/172/files Maybe a good question is: are there reducible collections that are not seqables

My guess is that the 1st arg needs to simply be a collection (upon which conj works)

yes - eduction is an example

@alexmiller just tried that:

(def e (eduction (map inc) [1 2 3]))
(seqable? e) ;;=> true

(this is CLJS)

well doesn’t implement Seqable

it is seqable via iteration in clojure

(seq e) ;;=> (2 3 4)

basically the question is: is the seqable? predicate sufficient for the args to into

but generally, yes they are independent protocols

so reducible-coll would be better right? in theory it’s possible to implement something that is reducible, but not seqable

yes

into is a reduction

yep

so, from should be a ::ss/reducible-coll, but the first arg only has to be something for which conj works. is there a protocol for that as well?

@alqvist has joined the channel

@andreas862 has joined the channel

welcome @andreas862

thank you - author of the massive into PR

I figured 🙂 can you read the discussion above?

yep, but awaiting response regarding to

someone on Stackoverflow suggests that the predicate for this should be something like this: https://github.com/clojure/clojure/blob/clojure-1.8.0/src/jvm/clojure/lang/RT.java#L649-L653

https://stackoverflow.com/questions/45247757/which-protocol-defines-conj-in-clojure

or there may already be one, maybe coll?

this kind of stuff is exactly why we are hesitant to spec parts of clojure

b/c anything you write will eventually be wrong - this stuff is intentionally polymorphic and not nailed down

right, conj may change. but so may our specs 🙂

yeah, but code will present as broken when not actually broken

part of the secret of stability/compatibility is to avoid saying things when you don’t have to - all these -ables you have are the places where you are trying to make something concrete that is intentionally not concrete

I understand the hesitation on making something official in the name of Cognitect/Clojure and sealing it for the future.

in speculative we have room to experiment and be wrong I think. if we come across reasons to change our -ables, we just fix it.

just highlighting that this is the kind of place where it’s appropriate to not fool yourselves or your users into believing this is The Answer

yeah

because everyone will be sad when it changes later

there must be something better than any? for the to argument?

btw, I think speculative is already more precise in some specs than other libs that try to do something similar

it will never be perfect and it may be good to write that down in the README

So the argument is that conj maybe could stop relying on clojure.lang.IPersistentCollection and that would break this spec?

and that core doesn't feel that IPersistentCollection is a part of any "structural" promise?

nil doesn’t implement IPersistentCollection, but it works with conj

In ClojureScript, coll? is associated with conj

ah, gotcha - Just staring at the function signature. Kotlin is nice with explicit nil types

So maybe it is (s/nilable coll?)

even if there is some baseline now, this is exactly the kind of thing where we want to be able to extend the language in the future

so boxing it in is just putting fences in the way of that - this is a philosophical thing embedded deeply in Clojure

One goal of ours specs is to capture wrong inputs. I think using anything more than any? is boxing things that might change in the future. I don’t think it’s unreasonable to expect these specs to co-evolve with future Clojure versions, but for now they are compatible with the most recent Clojure and CLJS releases

@borkdude why does (map inc nil) validate? nil doesn't seem like a sequential

maybe reduce is going to support another kind of protocol in the future. we can add an extra alternative to ::ss/reducible-coll. I don’t see the problem

@andreas862 sequential is something else than seqable. seqable also accepts nil

it’s not a problem, I just think it’s important to manage expectations

that is something we might need to work on. maybe removing the reference to clojure.core and the CA is an option. also putting words like ‘unofficial’ in the README.

this is up to @slipset as the CA and “hoping it would end up in clojure.core” are his ideas

I think it’s worth some sentences in the readme about some of the stuff I said above

there is pressure sometimes in trying to “nail everything down” and I think that comes at least partially from the static typing world (and partially from our programmer brains)

I think the message from Clojure and from Rich is - push back on that. don’t be afraid to leave ambiguity and room for future extension into your designs.

when you say “wrong inputs”, it’s important to keep in mind that that’s a perspective *at a given point in time*

right, as per clojure 1.10.0 and clojurescript 1.9.439

I think that specced core has a value even when it is version bound. The question is if the value is more or less than the cost of future problems. Some tooling aren't possible without specs. I think it would be interesting to explore that domain even if speculative only works with clojure x.x.x

On the other hand. If the fear is that the specs will restrict to a subset of legal code, then that is something problematic

I think there is definitely value to having specs, so I’m not trying to naysay that

I just think it’s useful to set expectations

My expectations for everything in life is low 😉 Anyhow I pushed another commit with (s/nilable coll?)

well that’s a good way to be more surprised than disappointed :)

@andreas862 looks good to me. one enhancement: can you make a ::coll spec in specs.cljc, we have the convention to use keywords instead of predicates. see: https://github.com/slipset/speculative/blob/master/doc/style.md

@alexmiller https://github.com/slipset/speculative/pull/173/files

would that be a good text for managing expectations?

Also see the text Speculative broke my project below it that I wrote a while ago

I’d be happy to remove the stuff about included in core as well. And the ca thingy.

I’m not actively hostile to those ideas 🙂 but they do set expectations. That’s why I suggested that.

clojure.core never asked for something like this. I never expect them to take any of this, but if they want, I’m not complaining.

which basically was my thoughts as well. And I figured that requiring a Clojure CA wouldn’t be to much to ask.

the text in the PR may be enough for now

if y’all agree with the content and the tone

Go!

yep, thx