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 <[email protected]> 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 <[email protected]> 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 [email protected]
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> [email protected]
>> 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 [email protected].
>> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
