lens offers holesOf , which is a somewhat more general and powerful version of this hypothetical function:

holesList :: Traversable t => t a -> [(a, a -> t a)]

Given a container, holesList produces a list of elements of the container along with functions for replacing those elements.

The type of holesList , like that of the real holesOf , fails to capture the fact that the number of pairs produced will equal the number of elements of the container. A much more beautiful type, therefore, would be

holes :: Traversable t => t a -> t (a, a -> t a)

We could implement holes by using holesList to make a list and then traversing in State to slurp the elements back in. But this is unsatisfactory for two reasons, one of which has practical consequences:

The slurping code will have an unreachable error call to handle the case where the list runs empty before the traversal is complete. This is disgusting, but probably doesn't matter much to someone using the function. Containers that extend infinitely to the left, or that bottom out on the left, won't work at all. Containers that extend very far to the left will be very inefficient to handle.

I'm wondering if there's any way around these problems. It's quite possible to capture the shape of the traversal using something like Magma in lens:

data FT a r where Pure :: r -> FT a r Single :: a -> FT a a Map :: (r -> s) -> FT a r -> FT a s Ap :: FT a (r -> s) -> FT a r -> FT a s instance Functor (FT a) where fmap = Map instance Applicative (FT a) where pure = Pure (<*>) = Ap runFT :: FT a t -> t runFT (Pure t) = t runFT (Single a) = a runFT (Map f x) = f (runFT x) runFT (Ap fs xs) = runFT fs (runFT xs)

Now we have

runFT . traverse Single = id

traverse Single makes a tree full of elements along with the function applications needed to build them into a container. If we replace an element in the tree, we can runFT the result to get a container with that element replaced. Unfortunately, I am stuck: I don't know what the next step might look like.