Closed josharnold52 closed 13 years ago
The above commit (pull request #37 ) addresses the issue. I was actually able to replace the Set[Int]
with just an Int
defining the # of nodes in the Zipper corresponding to the source child group. That suffices to reconstruct the correspondence if you make 2 assumptions:
These assumptions already held true for all Zipper instances, so nothing is really changing in terms of functionality. It's just that now those assumptions are required for ZContext to make sense, whereas before it allowed for more general mappings.
I'm so sorry it's taken me so long to get back to you on this. Basically, the new restriction is that the mapping end-points need to be contiguous for a particular element? I think that's a fairly safe assumption. In fact, it falls precisely within the constraints of normal sequence operations (map, flatMap, etc). I'm going to pull in your changes; thanks!
If Zipper.flatMap is used to replace one node with many, then Zipper.unselect does not preserve the order of the many. This is because a Map[Int,Set[Int]] is used to correlate elements from the original group to elements in the modified group, and Set makes no ordering guarantees.
For Zipper as it stands, I think the elements of that set will always form a contiguous range, so a Set might actually be overkill here. I'm going to try replacing it with a Range or similar and see if that holds up. Assuming that works, do you envision ever needing the more general correlation provided by Set?