On Dec 22, 2013, at 12:02 PM, Micha Niskin wrote: > Also, what about this: > > (loop [z (zip/seq-zip '((nil) 0))] > (if (zip/end? z) > :done > (do (println (zip/node z)) > (recur (zip/next z))))) > > Which produces: > > ((nil) 0) > (nil) > nil > 0 > :done
I think that's actually fine. The nil is visited and printed as any other element would be. Maybe you expect nil to be handled specially? I'm not sure why, but in any event this is not the issue that I raised. The issue I was rasing is that, when traversing '(() 0) with zip/next, one should first visit the root, then (), and then 0. But what actually happens is that between then () and the 0 one lands on a non-existent nil node. So one ends up visiting 4 nodes when there are only 3, and the extra one is a nil. As I mentioned previously this leads to null pointer exceptions in my application, and the only ways around it that I see are recoding everything without zippers or some nasty special case hackery. It's also possible that I just don't understand something fundamental about zippers and that this is supposed to happen. But if that's not true -- if it's really a bug -- then it'd be great if this could be fixed. 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.
