Oh, and of course you can use the amended version now to obtain the expected results:
(defn seq-zip "Returns a zipper for nested sequences, given a root sequence" {:added "1.0"} [root] (zipper seq? seq (fn [node children] (with-meta children (meta node))) root)) As noted in a comment on the ticket, clojure.zip/zipper's documetation actuals asks that the children argument return a seq of nodes. The rest of clojure.zip, however, expects nil when there are no children. One could argue that it is that expectation that needs fixing, but I think the current behaviour makes sense; perhaps the docstring should be adjusted, though. Cheers, Michał On 1 January 2014 00:53, Michał Marczyk <michal.marc...@gmail.com> wrote: > Ticket with patch at > > http://dev.clojure.org/jira/browse/CLJ-1317 > > The problem is that seq-zip uses clojure.core/identity as the > "children" argument to zipper. Applied to (), this returns (), but > clojure.zip expects the "children" function to return nil when there > are no children. The patch attached to the ticket above changes > identity to seq inside seq-zip. This suffices to fix the behaviour > discovered by Lee. > > Cheers, > Michał > > > On 1 January 2014 00:15, Lee Spector <lspec...@hampshire.edu> wrote: >> >> On Dec 31, 2013, at 5:08 PM, Armando Blancas wrote: >> >>> The implementation of seq-zip uses seq? as its branching predicate. As a >>> result the zipper goes down on () thinking it can have children: >>> >>> user=> (seq? ()) >>> true >>> user=> (seq? {}) >>> false >>> user=> (seq? #{}) >>> false >>> user=> (seq? []) >>> false >> >> Does that mean that you think that the behavior is correct and expected? >> >> It goes down () thinking it can have children -- fine -- but when there >> aren't any children shouldn't zip/next continue until it hits the next >> thing? Why should it "land" on a non-existent nil instead? >> >> Compare: >> >> Traversing '((1) 0) with zip/next we get 4 items: ((1) 0), (1), 1, 0 >> >> Traversing '(() 0) with zip/next we also get 4 items: (() 0), (), nil, 0 >> >> It seems to me that these shouldn't both give 4 things, since the second >> clearly contain one less thing. That alleged nil just isn't there. Note also >> that: >> >> Traversing '((nil) 0)) with zip/next we also get 4 items: ((nil) 0), (nil), >> nil, 0 >> >> That one seems right to me -- there really IS a nil there this time. But the >> one with () doesn't. >> >> If I'm alone in this then I guess I'll just write my own zip_really_next >> that does what I expect, but I'm curious if others also think that the >> current behavior is correct. >> >> Thanks, >> >> -Lee >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.