Comments on: Another angle on zippers

By: David Feuer

David Feuer — Mon, 03 Sep 2018 20:55:42 +0000

Sorry, I should have said weaker than Traversable, not the same.

By: David Feuer

David Feuer — Mon, 03 Sep 2018 20:53:48 +0000

It turns out that Holey is essentially the same as Traversable. Using a bleeding-edge bifunctors, you get traverseBia :: (Traversable t, Biapplicative p) => (a -> p b c) -> t a -> p (t b) (t c). The implementation of that function is itself very shady: it takes advantage of structure implied by Traversable that can't be obtained directly from its methods. You can then apply a funny continuation-passing biapplicative Roman Cheplyaka came up with to get a function holesIn :: Traversable t => t a -> t (a, a -> t a). See https://stackoverflow.com/a/49044894/1477667 for the full details. What this all means is that while it's certainly much easier, and likely more efficient, to get holes from generics, it's possible to get away with something weaker.

By: conal

conal — Tue, 06 Sep 2011 04:24:41 +0000

Robin: I wasn't suggesting that left & right are easy to implement. Rather that they might be unnecessary (pure speculation). Do you really want left & right instead of the list (or whatever functor element) of children?

By: Robin Green

Robin Green — Mon, 05 Sep 2011 00:15:21 +0000

I figured it out. It's necessary to go up, then down, then do a case split on all the possibilities (looking at both the derivative and the reconstructed upper level). It's not very simple at all!

By: conal

conal — Sun, 04 Sep 2011 19:42:13 +0000

Robin: does the remark following the type of down answer your question?

Since down yields an f-collection of locations, we do not need sibling navigation functions (left & right).

For instance, if f = [], then down yields a list of child zippers, which you can traverse as you like.

By: Robin Green

Robin Green — Sun, 04 Sep 2011 12:30:09 +0000

I’ve been trying to implement this in OCaml, and I kept thinking “How are left and right going to be implemented?” Now that I’ve come to implement them, I still don’t get it. You say that the interface is simpler because it doesn’t have left and right – but in order for that argument to hold, it must be simple to move left and right. How do you do it?

By: Conal Elliott » Blog Archive » Topless data

Conal Elliott » Blog Archive » Topless data — Mon, 20 Dec 2010 20:56:36 +0000

[...] « Another angle on zippers “Everything is a function” in Haskell? [...]

By: conal

conal — Mon, 09 Aug 2010 15:37:09 +0000

Brent: Thanks for the pointer to Conor's message. I guess I'd better follow the Haskell lists more closely. I like the Comonad connection!

By: Brent Yorgey

Brent Yorgey — Mon, 09 Aug 2010 14:45:33 +0000

Very nice. I like how this formulation removes the leftward bias inherent in the original version of "down". It also works for functors where there is no inherent ordering that can be placed on the children (I'm thinking here of things like general combinatorial species/quotient containers).

Also, a little while ago Conor McBride wrote a nice message to the libraries mailing list with the same version of down, as well as discard :: Loc f a -> a and decorate :: Loc f a -> Loc f (Loc f a) which make Loc f a comonad. decorate in particular gives a notion of "moving sideways" without having to go up and then back down.

By: Lucius Meredith

Lucius Meredith — Fri, 30 Jul 2010 17:54:17 +0000

Hey Conal,

Interesting. i don't know if you've seen my postings about using the notion of location as the notion of name. i gave a couple of write ups on my blog. If we use ∂µMxµM as the notion of location for a datatype given by functor M, then when M is secretly a bi-functor in which the other parameter is supplied by nominal structure, then we get solvable domain equations by setting the nominal parameter to be the derived notion of location. For example, the (syntax of the) λ-calculus (with an explicit term for divergence) is given by the bi-functor

M[V,A] = 1 + V + VxA + AxA

If we hold V fixed and calculate ∂µMxµM with respect to A, then we can set V = ∂µMxµM and get a solvable domain equation. The Haskell code for this structure is on my blog post. Now, what i haven't talked about, yet, is that we get a notion of inner product coming from these equations. Roughly, if names are "scalars", then intuition suggests terms ought to be vectors. So, then what should be dual to a vector? It needs to be a structure, say, k, such that when "dotted" with a term yields a scalar. Well, since we have set names to be pairs, (k,t), of contexts and terms, then we have the obvious operations k.t := (k,t). At this juncture there are several design choices. You can generalize the notion of inner product space by replacing the role of field with the algebra names inherit from the term algebra, and then show that you can recover a real inner product with encodings of arithmetic in terms of the term algebra, or you can begin with the encodings of the field operations in terms of the term algebra and pepper these through your definitions.

Best wishes,

--greg