[Haskell-cafe] xml conduit

[Michael Sloan]

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 <mgsloan at 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 <michael at snoyman.com>wrote:
>
>>
>>
>>
>> On Sun, Feb 10, 2013 at 8:51 PM, grant <thelff at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130210/e05ffccb/attachment.htm>