zipper: description describes rose trees. Should it?

[petertseng]

See how https://github.com/exercism/problem-specifications/blob/master/exercises/zipper/description.md describes possible zipper operations for a rose tree, but the first sentence tells us to implement a zipper for a binary tree. also note that https://github.com/exercism/problem-specifications/blob/master/exercises/zipper/canonical-data.json tells us to use binary trees

Thus, a potential improvement to the description could be to replace the rose trees operations with binary tree operations. This would make the README more applicable to the problem being asked. However, is there a disadvantage of doing that? Does it decrease learning in some way if the possible operations of the zipper are described in advance?

[petertseng]

Looks like the individual who asked about it in https://github.com/exercism/haskell/issues/546 never opened an issue in problem-specifications. And now it became my turn to do so.

[macintux]

There's a related problem with the exercise. It's not an insurmountable challenge by any means, but it does make it more difficult for someone who is attempting to solve the problem by understanding Huet's paper.

The paper describes go_left and go_right operations as moving left or right laterally within a list of children. The Exercism tests use left and right operations to navigate to the left and right children. From reviewing the tests this appears to almost be irrelevant, except by the dead_end test that expects an empty response when navigating to an empty child.

It's effectively impossible to implement the original Huet algorithm out of the box to solve the exercise because this concept doesn't apply to a rose tree (at least in this case, because the other child does exist; it would be fine if the test were attempting to navigate to either child of a leaf node).

Anyway, the fact that the Huet zipper algorithm doesn't solve this is probably not terribly important, but the naming of left and right combined with the README's confusion over the type of tree doesn't help with comprehension, and I'm wondering how many people are implementing a real zipper data structure vs some other type of tree.

Update: it's worth noting that I don't know OCaml and my CS days are long behind me, so it's possible I'm misinterpreting the Huet paper's use of trees. Take the above complaint with a few grains of salt.

Update 2: I did belatedly realize there is an obvious way to cope with the dead_end test while retaining the original algorithm (by storing the two values as two items of a list, including some indicator for the empty value, and juggling appropriately), so meh, maybe this is all irrelevant. Still confusing but perhaps that just adds to the educational experience.

[martinfreedman]

Just my two cents worth. I was looking forward to a rose tree exercise but this Zipper exercise is not it. I do agree in making it clear this is writing a Zipper for a binary tree. Are there are proper rose tree exercises apart from the refactoring exercise?

[SleeplessByte]

Just my two cents worth. I was looking forward to a rose tree exercise but this Zipper exercise is not it. I do agree in making it clear this is writing a Zipper for a binary tree. Are there are proper rose tree exercises apart from the refactoring exercise?

I don't think we have one, but that means it can be added!

[ErikSchierboom]

Yes, sounds look a great new exercise!

[martinfreedman]

This has C#, F# and Haskell examples.

[Lattay]

Hi,

The zipper exercise description is pretty offputting as it contains no instructions and talk about a completly different data structure. Can we rewrite that to make it informative? Can I just write a description and make a PR here for it to be reflected on all repos?

[IsaacG]

This exercise is being discussed on the forum. As such, I am closing out this issue to avoid duplicated discussions.