Err: That first link into Zipper.hs should instead be: https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L66
On Sun, Feb 10, 2013 at 9:40 PM, Michael Sloan <mgsl...@gmail.com> wrote: > I'm no lens authority by any means, but indeed, it looks like something > like Cursor / Axis could be done with the lens zipper. > > > https://github.com/snoyberg/xml/blob/0367af336e86d723bd9c9fbb49db0f86d1f989e6/xml-enumerator/Text/XML/Cursor/Generic.hs#L38 > > This cursor datatype is very much like the (:>) zipper type (I'm linking > to old code, because that's when I understood it - the newer stuff is > semantically the same, but more efficient, more confusing, and less > directly relatable): > > > https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L317 > > Which is built out of the following two datatypes: > > 1) parent (and the way to rebuild the tree on the way back up) is provided > by this datatype: > > > https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L74 > > 2) precedingSibling / followingSibling / node is provided by this datatype > (which is pretty much the familiar list zipper!): > > > https://github.com/ekmett/lens/blob/f8dfe3fd444648f61b8594cd672c25e70c8a30ff/src/Control/Lens/Internal/Zipper.hs#L317 > > > One way that this would be powerful is that some of the Axis constructors > could return a zipper. In particular, all of the axis yielding functions > except the following would be supported: > > parent, precedingSibling, followingSibling, ancestor, descendent, orSelf, > check > > This is because zippers can be used for modification, which doesn't work > out very well when you can navigate to something outside of your focii's > children. If we have a new datatype, that represents a node's payload, > then we could conceivably represent all of the axis yielding operations > except for parent / ancestor. However, those operations would be > navigations to payloads - further xml-hierarchy level navigation would be > impossible because you'd no longer have references to children. (further > navigation into payloads on the other hand, would still be possible) > > So, that's just my thoughts after looking at it a bit - I hope it's > comprehensible / helpful! An XML zipper would be pretty awesome. > > -Michael > > > On Sun, Feb 10, 2013 at 8:34 PM, Michael Snoyman <mich...@snoyman.com>wrote: > >> >> >> >> On Sun, Feb 10, 2013 at 8:51 PM, grant <the...@hotmail.com> wrote: >> >>> Michael Snoyman <michael <at> snoyman.com> writes: >>> >>> > >>> >>> Hi Michael, >>> >>> Just one last thought. Does it make any sense that xml-conduit could be >>> rewritten as a lens instead of a cursor? Or leverage the lens package >>> somehow? >>> >>> >> That's a really interesting idea, I'd never thought about it before. It's >> definitely something worth playing around with. However, I think in this >> case the Cursor is providing a totally different piece of functionality >> than what lenses would do. The Cursor is really working as a Zipper, >> allowing you to walk the node tree and do queries about preceding and >> following siblings and ancestors. >> >> Now given that every time I'm on #haskell someone mentions zippers in the >> context of lens, maybe lens *would* solve this use case as well, but I'm >> still a lens novice (if that), so I can't really speak on the matter. Maybe >> someone with more lens experience could provide some insight. >> >> Either way, some kind of lens add-on sounds really useful. >> >> Michael >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe