Add reusable zipper buffers

[imlvts]

This introduces ZipperBuffer. This allows re-using zipper path and stack Vecs.
Name up for change, don't have a strong preference.

fn ReadZipper::detach(self) -> ZipperBuffer; // saves path
fn ZipperBuffer::attach(self, &map) -> ReadZipper; // restores path
fn ReadZipper::relocate(self, &map) -> ReadZipper; // same path on a different map

detach + attach, relocate preserve the path. might need to change the API so this is explicit.

A few additional non-public API changes to make it work.
descend_to_byte used instead of descend_to to avoid aliased &mut.

[adamv-symbolica]

Nice! I quite like the API and naming.
The ancestor_node thing is a little ugly, but the lifetime tagging makes sense.
What's the motivation for going for a new object, rather than just a "disabled RZ" which is a zero-overhead opaque-type wrapper of a RZ?

[luketpeterson]

I'm ok with the API concept. I'd prefer different names for detach and attach. And I think relocate has some issues.

The word detach doesn't say enough about what it does. It sounds too fundamental for an optimization like this. We could use the rust idiom for a consuming conversion, i.e. into_buffer or into_zipper_buffer (I prefer the latter). Another option is to make it clear we're destroying the zipper but saving the buffers with salvage_buffer. I think I like into_zipper_buffer.

On the word attach, same issue. That verb sounds really central to what a zipper can do conceptually. Which this API isn't. My preference would be variants of PathMap::read_zipper_with_buffer(&self, buffer: ZipperBuffer<V, A>).

ZipperBuffer::into_read_zipper(map: &'map PathMap<V, A>) could work, but. I have a fairly strong preference for read_zipper_with_buffer because it establishes a pattern that could work with ZipperHead methods too. (_unchecked ZH methods are what MORK will really want, I assume)

As far as relocate, my issue is the same as with attach / ZipperBuffer::into_read_zipper It assumes a PathMap so we'd need to create a different API shape for a ZipperHead. And it is basically a convenience. But anyone who is looking for this API wants runtime performance over convenience.

[adamv-symbolica]

I think the most important part not covered there is that you want to take these zippers at a path, you may not have access to the root, nor want to pay the cost of re-descending.

[luketpeterson]

you may not have access to the root

There are two possible interpretations of what you might want: 1. The ZipperBuffer represents the path, and 2. The ZipperBuffer represents the origin_path. An API limited to basing on PathMaps makes this distinction irrelevant.

But if I assume you want 2. it does mean there is now a failure mode where the beginning of the buffer deviates from the origin_path above the ZipperHead location, making it impossible to create zippers with some paths from some ZipperHeads.

So the ZH version of ZipperHead::read_zipper_with_buffer would need to return an Option or Result (Probably a Result, since it is an arg error)

nor want to pay the cost of re-descending.

Some amount of re-descending is unavoidable. There is no way a node stack can be transplanted from one base to another without redoing the work to descend from the new base.