Fork me on GitHub

I'm still puzzled by eduction and what others claim about that. Both Alex Miller ("eduction is pretty specialized in that it is a delayed eager evaluation") and Chouser ( - at the very end) seems to suggest that the whole sequence is realized once you ask for the very first element. However, my experiments suggest something else (only the first chunk is realized): Am I missing something?


The source of clojure.core.Eduction clarifies what's happening here a bit.

(deftype Eduction [xform coll]
   (iterator [_]
     (clojure.lang.TransformerIterator/create xform (clojure.lang.RT/iter coll)))

   (reduce [_ f init]
     ;; NB (completing f) isolates completion of inner rf from outer rf
     (transduce xform (completing f) init coll))

eduction gives us something that implements Iterable (and thereby is seqable), and IReduceInit If you treat it as a seq, then the work is done lazily in chunks, but if you just educe it some more, all the transformations fold together, and no work is done still.


@jumar You also might wanna re-watch the "Transducers" talk at Strange Loop where eduction was implemented by using sequence for the seq part and transduce for the IReduceInit part (as it still is...)


Does this help?

user=> (def xf (map #(do (println %) (inc %))))
user=> (def e (eduction xf (range 5)))
user=> (def s (seq e))
user=> (first s)
user=> s
(1 2 3 4 5)
user=> s
(1 2 3 4 5)
user=> (def more-e (eduction xf e))
user=> (into [] more-e)
[2 3 4 5 6]
user=> (into [] more-e)
[2 3 4 5 6]


Subsequent calls to s doesn't do the work again and again because that's a lazy seq, whereas uses of IReduceInit on eductions do the work each time.


Thanks for the explanation but I'm not sure I'm following. Here we are talking about eduction, when used as IReduceInit (via into) doing the work again and again (which is eduction's contract basically). However, I'm talking about the impression I get from the comments above when they claim that when you realize just the first element you somehow get the whole thing realized. Is that because I treat it as a lazy seq via first? What else I should be doing to "realize only the first element" yet get the whole thing realized? into is obviously going to realize the whole thing so I'm not sure how is that different from sequence or any other transducers related stuff


@U883WCP5Z any insights into this part?


sequence is not lazy in the output production, it's lazy in the input consumption. This is because transducers can be expansive. For example, if we have a mapcat in our transducer, consuming one input may produce multiple outputs, so all those will get realized.


Transducers can also be reductive, so a filter in the transducer means putting one input in may give us no output, so the impl of sequence and the seqable part of eduction, when asked to realize one element (by calling first perhaps) will keep feeding inputs until an element is realized. But more than one may be realized, because of expansive transducers.


Right, I think I got this part. But still, my original question is about eduction and that the people claim it should consume all the input elements once asked for the first element (as Alex called it "delayed eager evaluation"). But that's not what I observe. Or perhaps I misinterpreting them?


"delayed eager evaluation" correctly describes the IReduceInit part of eductions. We can keep creating more eductions from eductions, and all that happens is the recipes are combined, not executed. That's the "delayed" part. The "eager" part is if used with IReducedInit, if seq is called on it, then it isn't eager.


So Eductions do provide "delayed eager evaluation" but also "delayed lazy evaluation" by being seqable.


Hmm, that makes sense but is it then different from sequence (apart from the caching stuff)?


Maybe @U064X3EF3 could shed some light on this; that is how was the "delayed eager evaluation" meant.

Alex Miller (Clojure team)19:10:35

maybe I shouldn't have said "eager" there

Alex Miller (Clojure team)19:10:36

it's a delayed reduction, how eager it is depends on what you do with it


Ah, okay - that makes more sense 🙂. Thanks!


Btw. it was a good point with seq and subsequent calls not re-realizing the "collection" backed by eduction, but when I just try via first two times then it's being realized two times:

(let [xs (eduction (map #(doto % print inc)) my-seq)]
  (first xs)
  (first xs))
;;=> prints: 


compared to sequence which realizes only once:

(let [xs (sequence (map #(doto % print inc)) my-seq)]
  (first xs)
  (first xs))
;; prints:


Each time we call seq on eduction, the work is done again. eduction itself isn't a seq, it's seqable, meaning we can call seq and get back an ISeq, and each time we do this on an eduction, we do the xform again.


Try this:

(let [xs (seq (eduction (map #(doto % print inc)) my-seq))]
  (first xs)
  (first xs))


> Btw. it was a good point with seq and subsequent calls not re-realizing the “collection” backed by eduction, but when I just try via first two times then it’s being realized two times: The reason for this is that (do (first e) (first e)) is essentially (do (first (seq e) (first (seq e)). i.e. you’re throwing away the intermediate lazy seq. It’s different to (let [s (seq e)] (first s) (first s) as there you hold onto the lazy seq for the second call to first and benefit from the caching the lazy seq provides.

Prateek Khatri10:10:50

Using, can I create a schema which has an OR condition on a map’s keyword? For example, I want to make sure that only {:handler {s/Keyword (s/pred #(fn? %))}} or {:handler-fn {s/Keyword (s/pred #(fn? %))}} should be allowed. This basically says that only :handler or :handler-fn is allowed in this map’s first key. What would a schema look like in this case?


@UM6UT4D5L this works?

(s/defschema MySchema (s/either {:handler {s/Keyword (s/pred #(fn? %))}}
                                 {:handler-fn {s/Keyword (s/pred #(fn? %))}}))


(s/validate MySchema {:handler-fn {:key1 identity}})

Prateek Khatri11:10:10

@U7ERLH6JX Thanks! It worked 🙂


hey guys, quick question. I am doing some clojure parsing and just came across the case of the keyword :/. It is hard-coded in the test.check library but from what I understand from both edn format spec and clojure reader website this should not be a valid keyword. Is this a bug or are the docs outdated ? :thinking_face:


According to the reader spec, "Keywords are like symbols", and / is a valid symbol: Maybe that's why?


mmmm maybe I am misreading this edn spec? > / by itself is a legal symbol, but otherwise neither the prefix nor the name part can be empty when the symbol contains /.


so / is legal but he/ is not ?


I believe the quick answer is that there are multiple functions for reading Clojure code and edn, and they are not all identical in what they permit vs. what they do not permit. If you want a bright shiny line between legal vs. not legal, you will find implementations that differ slightly, and the English specs are slightly ambiguous in some of these corner cases.


When you say that the keyword :/ is hard coded in the test.check library, I am not sure what you mean. Do you mean that keyword appears in test.check's source code?


Clojure's built-in reader accepts :/ as a keyword, apparently. Not something I had ever tried before.


this is what I meant with hard-coded It seems that it was made on purpose since it cannot be generated the “standard way” or at least it would be quite difficult.


what does "cannot be generated the standard way" mean?


based on reading the other code, adding a special case to frequency seems to ensure known degenerate cases are exercised

Alex Miller (Clojure team)19:10:08

Gary and I had an extended conversation about this. Unfortunately, I don't remember any of it. :)

😄 16
Alex Miller (Clojure team)19:10:42

but he probably does, and there may even be a test.check ticket about it

Alex Miller (Clojure team)19:10:54

or at least check the blame for the commit


That case was added to test.check generator with this commit: . Commit message mentions adding it explicitly, but not sure if there is any further recording of details of why.


test.check has code for programmatically and pseudo-randomly generating a large variety of what it considers valid data, and probably :/ was not easily generated via the "general case" code, so he added a special case to make sure it was generated with a minimum frequency, which from the code I would guess is at least 1/(100+1) fraction of the time, but that is only my guess there.


It also is not clear to me how from reading this page that you conclude :/ is not a valid keyword?


But as I mentioned earlier, the English is likely to be slightly ambiguous in these kinds of corner cases.


oh no, I thought that from the edn spec. See message above. The part on the prefix, name part 😅


In any case, at least now I know that this is an intentional case and not a bug which is why I tried to figure out. Thanks a lot guys 🙂


project idea: Smiley Oriented Programming:

(def happy (keyword ")"))
(def sad (keyword "("))

(println "yay!" happy)
(println "aw." sad)


question: given clojure map, how to convert it to java HashMap? bonus if the same can be done recursively for map of maps of maps of lists of sets etc... so sets to HashSets, Lists to ArrayLists, maps to HashMaps?


(new HashMap {:a 2 :b 2})) works transparently 🙂


clojure maps implement java.util.Map. Does it specifically have to be a HashMap? (doto (java.util.HashMap.) (.putAll {"foo" "bar" :baz :quux}))


hmmm not specially 🙂 ok need to test that


Okay it works. What about keywords? If something is keyword in clojure, how can I ask for that key


like {:key "Value"} in clojure But how would Java treat the :key part of the map? What would be the key I have to put for such a map, to get the "Value" ?


The usual ways. (:key (java.util.HashMap. {:key "Value"})) (get (java.util.HashMap. {:key "Value"}) :key) (.get (java.util.HashMap. {:key "Value"}) :key)

Alex Miller (Clojure team)19:10:40

are you asking from the Java side?

Alex Miller (Clojure team)19:10:59

the key will be a clojure.lang.Keyword instance in the Map, if so


thanks, all looks fine now and working


from the java side you can use the invoke method of clojure.core/keyword to get a keyword from a string for lookup


there might even be something for this in RT (of course you can also just use the read method on ":foo")