Talk:Haskell/Zippers

One of sigfpe's comonad articles shows a simple zipper-like structure for lists. I think that would be a good way to introduce the idea. We don't have to take the comonad stuff, of course :-), but lists are simpler to think about than trees -- Kowey 14:19, 4 January 2007 (UTC)

Solutions to exercises
I came up with this; it compiles and seems right, but it's unclear how one would check it's right. --Gwern (contribs) 03:50, 23 February 2007 (UTC)

put :: a -> Node a -> Node a put n (DeadEnd _) = DeadEnd n put n (Passage _ a) = Passage n a put n (Fork _ a b) = Fork n a b

get :: Node a -> a get (Passage x _) = x get (DeadEnd x) = x get (Fork x _ _) = x


 * Yes, that's the intended solution. What do you mean with "how to check it's right?" -- apfe&lambda;mus 09:39, 20 February 2007 (UTC)


 * Exactly that. I mean, I took the type signatures, thought about it a little bit, fixed it until the compiled, but after that how do I know it really does what it is supposed to do? I have no data to really check it on. --Gwern (contribs) 01:54, 21 February 2007 (UTC)


 * Why do you need to check something if you can prove that it's correct? :) I think the problem is that the specification of  and   has been rather vague. I changed it, is it better now? -- apfe&lambda;mus 12:19, 22 February 2007 (UTC)


 * I think it looks better, though I'll go back and actually try it later. As for proofs, well, I'd need a proof that my proof is correct first. --Gwern (contribs) 03:50, 23 February 2007 (UTC)

There's something wrong with this definition, I think. retrieve has the type, which is to say it returns  , but   has the type  , so   is being returned where   is expected.


 * Oops, it's an error in the type signature. I corrected it to
 * -- apfe&lambda;mus 09:39, 20 February 2007 (UTC)

Regarding the Chain Rule
In the article "We close this section by asking how it may happen that rules from calculus appear in a discrete setting. Currently, nobody knows." but doesn't sigfpe's blog give a reasonable answer with finite differences http://blog.sigfpe.com/2009/09/finite-differences-of-types.html ? 72.235.236.112 (talk) 17:43, 26 June 2010 (UTC)


 * Ah, sure, but his finite differences are even weirder. :-) What I mean is that it's not clear why these kind of rules have a meaningful interpretation; their interpretation in a calculus setting is very different, after all.
 * -- apfe&lambda;mus 07:49, 27 June 2010 (UTC)

Connection between Differentiation and Zipper
I have some problems with understanding. When I make a hole in a data structure, then the root of the data structure is still the same (unless you made the hole where the root was). However in the article it looks like additional to putting a hole into the datastructure, the hole is also made the root of the datastructure. It seems, that the data type definition is the same, both for the "hole in the middle" and "hole at the root" interpretation. Is this generally true? How about a mutually recursive definition of a datatype? E.g. data A x = Node (B x) (B x); data B x = End | Cons (A x) (B x). How about the second derivative of a datatype? The datastructure gets two holes, but they cannot be both at the root. HenningThielemann (discuss • contribs) 18:53, 20 January 2012 (UTC)