Dear Haskell didacts, I am pleased to announce that http://en.wikibooks.org/wiki/Haskell/Zippers now features "Theseus and the zipper" and "Differentiation of data types". Of course, comments, corrections and criticism are welcome! Regards, apfelmus
On 19/02/07, apfelmus@... <apfelmus@...> wrote: > Of course, comments, corrections and criticism are welcome! The second section, then: 1) Formatting: IMO it'd look better if the formulae were left-aligned. 2) It's currently sitting a little oddly. I think the way to take this is to write an 'Algebra on Datatypes' article which explains what 1, 0, +, * etc. mean in the concept of types and also show some elementary results like distributivity of * over +, c.f. normal algebra, and so on. We would also need to explain isomorphisms as they're really important but we can't really assume them. Then we link to that article as essential background reading before tackling the zippers bit. We should also move the differentiation bit to the Algebra on Datatypes article, which would enable the focus in the zippers article to remain a bit more; at the moment there's something of a discourse at the beginning of the second section. Nearing the end of the AoD article we would link to the Zippers article and say 'Check out a really cool development of this'. 3) The notion of a 'one-hole context' isn't fully explained; it's an odd concept to begin with and we don't really develop it enough. We should say something like 'Imagine a datastructure parameterised over a type, like trees, lists etc.. If we were to remove one of the values of this type from the structure and replace it with a placeholder indicating we've just removed something, we obtain the one-hole context for that removed object.', then back it up with examples,(Continue reading)
On Mon, Feb 19, 2007 at 11:25:47 +0100, apfelmus@... wrote: > now features "Theseus and the zipper" and "Differentiation of data > types". Of course, comments, corrections and criticism are welcome! wow! i unfortunately haven't gotten around to reading the 'hard' part of the tutorial yet... but in the meantime... wow... i'm almost tempted to mail huet himself-- -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
_______________________________________________ Wikibook mailing list Wikibook@... http://www.haskell.org/mailman/listinfo/wikibook
On 19/02/07, Eric Y. Kow <eric.kow@...> wrote: > i'm almost tempted to mail huet himself
The following applies only to the first section, for now, which is all I've read. On 19/02/07, apfelmus@... <apfelmus@...> wrote: > Of course, comments, corrections and criticism are welcome! I made a single correction and expanded on one quick point: http://en.wikibooks.org/w/index.php?title=Haskell/Zippers&diff=760692&oldid=760465 My comments, then: 1) Any reason you're not using the standard camelCase? 2) Any reason the maze datatypes take an extra parameter? For simplicity, I'd have expected: data Node = DeadEnd | Passage Node | Fork Node Node And so on. 3) You could do with splitting the first section into various subsections, it's a bit long and unwieldy as-is. 4) I'm not sure I like the typesetting of the conversation using lots of <br>s, but I can't think of a better way of doing it off the top of my head.(Continue reading)
David House wrote: > 1) Any reason you're not using the standard camelCase? Not really, but I wanted to avoid any confusion between the constructor TurnRight and the function turnright. > 2) Any reason the maze datatypes take an extra parameter? For > simplicity, I'd have expected: > > data Node = DeadEnd > | Passage Node > | Fork Node Node Well, this is too simple :) Without an extra parameter, why would you want to run around and look at the subtrees? I mean, there's nothing interesting at their top. > 3) You could do with splitting the first section into various > subsections, it's a bit long and unwieldy as-is. Yes, subsection are a good idea. As of now, Gwen already did a split. > 4) I'm not sure I like the typesetting of the conversation using lots > of <br>s, but I can't think of a better way of doing it off the top of > my head. Yeah, I'm not happy about it, too. The article in the "Scientific American" did the same, but as there were multiple columns, it looked better.(Continue reading)
On 20/02/07, apfelmus@... <apfelmus@...> wrote: > Not really, but I wanted to avoid any confusion between the constructor > TurnRight and the function turnright. Seems like a weird point to break convention on, so I've changed it to use camelCase. Breaking from convention will likely cause as much confusion as the similarity in naming. Change back if you have strong objections. > Well, this is too simple :) Without an extra parameter, why would you > want to run around and look at the subtrees? I mean, there's nothing > interesting at their top. To solve the maze? Sure, there's nothing to look at on the way, but you're trying to write a computer program maze here, the point of manipulating Labyrinths is to get to the end! :) Which makes me think; we could do with a Center constructor to indicate the end of the labyrinth. > > 6) I don't think you spend enough time with the zipper concept. I > > found when I read Huet's paper that zippers were one of those > > brain-exploding concepts, perhaps because everything is stored > > backwards. A few suggestions that would have helped me: > > > > * We store the entirety of the labyrinth in any zipper; by zipping all > > the way to the top so that the focus is at the entrance, the > > sub-labyrinth is the whole labyrinth. The reason this is done is so > > that we can backtrack and take an alternate path at any point. > >(Continue reading)
David House wrote: > Seems like a weird point to break convention on, so I've changed it to > use camelCase. Ah, you're right, it doesn't look confusing at all :) >> Well, this is too simple :) Without an extra parameter, why would you >> want to run around and look at the subtrees? I mean, there's nothing >> interesting at their top. > > To solve the maze? Sure, there's nothing to look at on the way, but > you're trying to write a computer program maze here, the point of > manipulating Labyrinths is to get to the end! :) Which makes me think; > we could do with a Center constructor to indicate the end of the > labyrinth. Can be quite difficult to run around in a completely dark labyrinth :) I also intended the extra parameter to hold (x,y)-coordinates for the nodes to allow north-east and so on. In the picture, the concrete labyrinth and the abstract structure look quite different. >> Reading your remarks, I agree that the explanation of the first example >> needs improvement. But I'd not showcase a second example. I mean, in the >> end, the reader can only learn to construct a zipper by constructing one >> himself, not by being showed how to construct one. Of course, he cannot >> do the construction if he gets stuck with the showed example. > > I'm in fairly strong disagreement here. The example of a single zipper > may not suffice, just as one explanation of a complicated concept will > never do for everyone. People need to look at things from different(Continue reading)
apfelmus@... wrote: > Perhaps it's best if I improve the explanation and we return to the > discussion afterwards? Ok, I've managed to expand the explanations and to add several images. >>> And don't worry, there is enough material for the "Algebra of Data >>> Types" to explode :) (sums and products, (polynomial) functors, >>> F-algebras, coalgebras, universal properties, fixed points (inductive >>> and coinductive), etc.) >> >> Tasty :) Something I know little about, but sounds great. Any papers >> for background reading? > > Personally, I read > > http://www.cs.chalmers.se/~patrikj/poly/afp98/ > > but it's huge and I actually skipped most of it. The most interesting > point was the meaning of "F-Algebra". Otherwise you may skim through > > http://haskell.org/haskellwiki/Research_papers/Generics > > but there is indeed a need for a good tutorial. I think that "Fold and Unfold for Program Semantics" by Graham Hutton may be helpful, too. While it does not really explain that functors can be see as signatures for algebras (monoids, natural numbers, etc.), it puts their folds and unfolds to good use.(Continue reading)
RSS Feed