Probably because it was simpler (and safer) to keep the existing implementation, rather than rewrite all of that code?

Fair enough; safer. Simpler, is it really? Slightly different code in two places executing something that hopefully ends up being the same in the end. Surely it would be simpler to just issue the call to the other arity?

Sorry, I meant the process would be simpler: of only adding the new arity and not touching the existing code.

Ah, yes.

Transducers are inherently greedy. And the core functions are mostly inherently lazy. I would expect some difficulty making those congruent. No?

(map f coll) = (sequence (map f) coll) is lazy.

And you can do some funky things with eduction to make it super-lazy (and skip chunking)

I think that’s one of the really neat things about transducers: they can be lazy or greedy as required, given the context they’re used in.

eduction produces a reducible, not a lazy sequence, but yeah eduction is an interesting one...

I definitely did not know that.

No, you’re right. I mean, you can make it behave lazily. I’ll whip up an example.

Education doesn't cache values

It's probably worth noting that the chunking behavior of sequence does seem to match the core lazy functions tho'...

Don't the core functions do chunking too? How does it differ from sequence?

(defn print-inc
  [n]
  (println "inc" n)
  (inc n))


(defn print-even?
  [n]
  (println "even?" n)
  (even? n))


(->> (range 1000)
  (map print-inc)
  (filter print-even?)
  (take 2))
;; 64 printlns


(sequence
  (eduction
    (map print-inc)
    (filter print-even?)
    (take 2)
    (range 1000)))
;; 8 printlns

sequence constructs an iterator then builds chunking and a seq on top of the iterator

So it doesn't chunk based on the chunking of the incoming seq

(take 2 (filter #(do (println "n" %) (even? %)) (range 100)))

(take 2 (sequence (filter #(do (println "n" %) (even? %))) (range 100))) 

@U06B8J0AJ In addition to Sean's first answer, this ^ likely also contributed to the decision not to reimplement. Some potential for breakage of code built around old chunking size.

Well, if you skip eduction, the behaviour is identical. Edit: no, I seem to be wrong.

(sequence (comp
            (map print-inc)
            (filter print-even?)
            (take 2))
  (range 1000))

(transduce (take 2) conj [] (eduction (filter #(do (println "n" %) (even? %))) (range 100)))

Code shouldn't rely on chunking size -- it's an implementation detail 🙂

Yeah, indeed

Reducing over range directly skips creating a seq so there is no chunking

Things get weird combing a chunked seq like from a vector with sequence, because the vector seq and the iterator seq from sequence could have differing ideas about chunks

Core Team won't guarantee the implementation details, but they definitely still seem to weigh such breakage potential as a meaningful factor regardless.

Yeah, possibly. So we have two theories: • Minimum amount of update to the codebase needed, and • Keep some implementation details from changing

Those aren't conflicting theories, if that's not clear. I would bet the first one held more weight.

No, could be either or both, or some unknown third case. “Couldn’t be arsed”, “the existing code has a special place in my heart”, etc.

Or perhaps, performance characteristics that would change slightly, but unnecessarily.

I wonder if Clojure would have looked slightly different if protocols and transducers had been there from the beginning.

I think Rich has said "yes" about that at some point...?

(def. about protocols -- but I think also about transducers too)

Aha! How uncharacteristic. I know from the anniversary chat that he doesn’t subscribe to the many-worlds theory 🙂

Well, the implementation would be different. The language would be largely identical I suspect.

There would probably be less Java and more Clojure if protocols were there from the start.

Even if the language wouldn’t change, it might have had an impact on codebases. We might have seen more extends around. And, I guess, fewer ->>s if transducers were imprinted on users early on.

It’d probably be a mixed bag, just like now.

Do you want to simply add that jar to the classpath? If so, you can use :local/root within :deps: https://clojure.org/guides/deps_and_cli#local_jar

Awesome suggestion as usual @U2FRKM4TW! This is what worked in the end:

{:paths ["src"]
 :deps {io.github.nextjournal/clerk {:mvn/version "0.11.603"}
        link.szabo.mauricio/spock {:mvn/version "0.1.1-SNAPSHOT"}
        jpl/jpl {:local/root "./resources/jpl.jar"}}
 :aliases {:prolog {:jvm-opts ["-Djava.library.path=./resources"]}}}

also pinging @U3Y18N0UC as this is probably worth of inclusion in the spock readme