Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zippers: Making Functional "Updates" Efficient (2010)

goodmath.org

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Zippers: Making Functional "Updates" Efficient (2010)

#12

Post by clarkmoody »

hombre_fatal wrote: post #9
clarkmoody wrote: post #8

I've used the zipper concept with lists for making impossible states impossible [0] in the context of Rust programs. The rich enum type in Rust creates opportunities to avoid bugs by baking small state machines into the code everywhere, like loading data in the linked example. A concrete example is for managing the active item in a list. Instead of storing the active item as an index into the vector like this: struct…

What does the second List impl offer over the first one? It's the API that makes something impossible to misuse, and they could offer the same API like List.create(x: T, xs: T[]), but the first one is simpler.

In one version I've seen, the active element is of a different type, offering enhanced functionality over the vectors of next and prev items:

  struct List {
    prev: Vec,
    active: A,
    next: Vec,
  }
This could be used for some active type that has ephemeral cache information or state associated with it (view state in a GUI app, for instance). The inactive type may be hydrated and converted to active, and the active type can be archived into an inactive type.

Re: Zippers: Making Functional "Updates" Efficient (2010)

#13

Post by clarkmoody »

johnfn wrote: post #10
clarkmoody wrote: post #8

I've used the zipper concept with lists for making impossible states impossible [0] in the context of Rust programs. The rich enum type in Rust creates opportunities to avoid bugs by baking small state machines into the code everywhere, like loading data in the linked example. A concrete example is for managing the active item in a list. Instead of storing the active item as an index into the vector like this: struct…

I tend to like the idea of making impossible states impossible, but your particular example seems to have a number of negative tradeoffs. For one, it's more complex than the original data structure - a simple call like .map() is now a fairly chunky operation, and if you want to filter after that, you really have a mess on your hands. Additionally, you seem to have traded off one set of "state we shouldn't allow to be…

The iterator can be implemented fairly simply:

  self.prev.iter()
    .chain(iter::once(self.active))
    .chain(self.next)
I'm not sure what you mean by including active in another position, but see my sibling comment that makes the active element of a different type, for another wrinkle on this thing.

Re: Zippers: Making Functional "Updates" Efficient (2010)

#16

Post by rkangel »

clarkmoody wrote: post #8

I've used the zipper concept with lists for making impossible states impossible [0] in the context of Rust programs. The rich enum type in Rust creates opportunities to avoid bugs by baking small state machines into the code everywhere, like loading data in the linked example. A concrete example is for managing the active item in a list. Instead of storing the active item as an index into the vector like this: struct…

How do you represent an empty list with this approach?
Post reply on HN