Thank you for the comment. My understanding of finger trees is that they’re sort of a general framework for defining many different types of data structures (e.g.: balanced search trees, covering as special cases most of the structures in the “Purely Functional Data Structures” book). So in that sense, they provide efficient functions for searching a container, and they may provide functions for mapping a function over a container, but I don’t think they’re especially useful for incrementally walking a data structure.

For folks not familiar with finger trees, I like this page (the link to the original paper on finger trees is there as well):

http://apfelmus.nfshost.com/monoid-fingertree.html

Since finger trees are just another algebraic data type, you could take their derivative to put them in Iterable. Although, as you and Matt have suggested, arbitrary updates are a little problematic and might be handled better with either finer-grain control (e.g.: MutableIterable, MutableIterator) or with sufficiently intelligent implementations of Iterable (so that arbitrary updates don’t invalidate set/finger-tree invariants).

However, your post does not touch at all the topic of *insertion* of a new item into the structure.

I have found out that the Finger Tree data structure solves all these problems.

Oops, you’re right about the redundant descend functions. I’m not sure how those got in there, but I’ve taken them out.

I’m not sure that I completely follow your distinction with the “OO iterator”. Are you saying that the OO iterator doesn’t support updating? I can see how updating an arbitrary element in a set would cause problems (although that could be accounted for in the set iterator definition — similarly to how it’s already accounted for when you insert a redundant element into a set). However (that issue aside), if you represent a set as a list or as a binary tree, these iterators should work.

You’re right; I should have posted this in Literate Haskell. Thank you for the suggestion.

P.S. Is it possible to shorten the second definition of forward to:

forward c@(t, (Left t’):p) = forward (up c)

(likewise backward), or have I missed something?

P.P.S. It’s be awesome if you could post in Literate Haskell so it’s easier to copy and paste the source to play around with this stuff.

I’ll assume you’re not joking (please ignore the rest of my response if you were joking).

You’re comparing apples to oranges. It’s actually quite easy to *use* these iterator types (in fact, that’s the point of putting them in these convenient type-classes). In the same way, it’s easy to *use* array-indexing/mutation in C. However, a fair comparison is between this category of type-classes and the compiler-machinery in C that makes “a[i].x+=5″ possible.

When *using* these iterators, you could write something like the following to update the 4th value to “foo”:

update (iter_n (open A) 3) “foo”

Even that is a bit long, but it’s pretty much the same as what you’d write in C++ to do the equivalent thing to a linked list:

*(iter_n(A.begin(), 3)) = “foo”

Plus, the update in the Haskell version is purely-functional — so you can revert to the previous state if necessary or do something with both states, etc.

You might make an argument that the Haskell version is difficult, because you have to figure out how to iterate over some new data structure that you come up with. However, there’s a straightforward procedure to find that type (it’s just the derivative — and the compiler itself could do this for you in theory; a future GHC probably will). OTOH, if you provide iterators for your own data structures in Java/C++, you have to write this kind of code anyway.

Finally, I think I’m a living contradiction to your argument that you have to be in the “brainiest 1% of the planet” or have a PhD to understand this.

Seems like incremental update is only accessible to the brainiest 1% of the planet when using functional languages.

The rest simply use a[i].x += 5 or somesuch, with need for fingers or zippers or a PhD.