Daniel Mlot wrote:
About the writing of "Truth Values" and the reworking of "Type Basics" (which I started yesterday) there are two main outstanding questions:
1. In "Truth Values" your outline included introducing True/False pattern matching when discussing the boolean operators. At first I thought it wasn't a good idea, as explained on the Talk page. But now, after having a closer look at "Type Basics" and the examples therein, I realize that not introducing an idiom this elementary idiom early on might be pedagogically problematic, as it may induce newbies to do very simple things in obtuse ways (like defining something like (||) with guards). In that case, a brief example - with (||), not, etc. could easily be added to the Boolean operations section, but I am not sure on what would be a clear, simple and not misleading way of introducing pattern matching at this point (discussing the general PM concept would likely not work, and saying "you can define functions with multiple definitions in terms of cases for (quasi-literal?) values of the arguments" could get too confusing (mainly the "quasi-literal" part - which really means literals and argument-less constructors, but obviously we can't go that far at this point of the book).
I like Graham Hutton's way of introducing pattern matching a lot. (chapter 4.4. of Programming in Haskell). He starts with the obvious not False = True not True = False repeats the "complete case analysis" concept with True && True = True True && False = False False && True = False False && False = False Then, he introduces wildcards True && True = True _ && _ = False and variables True && b = b False && _ = False as a way to keep the number of cases down. Finally, he mentions the common pitfall that b && b = b _ && _ = False does not work and notes the correct solution b && c | b == c = b | otherwise = False The point is that a handful of simple examples are the most concise and clear way of introducing pattern matching (or any other concept); there is no need for "the most general explanation" because humans learn very well from concrete examples that can be repeated and adapted. (One could say that this is an instance of the "show, not tell" tenet.)
2. I am starting to believe that "Type Basics" should be divided in two. More specifically, the first part would retain the introduction, the experiments of :t, the presentation of Char and String and the section about functional types. The second part would have the final section about type signatures in code and the new section on number types. Finally, "Lists and Tuples" would be sandwiched between the two parts.
Sounds good. :) Personally, I would cut a lot to make it shorter and more "digestible", though; which might make a split unnecessary. The more elaborate discussion can always be taken up again in the subsequent "Elementary Haskell" track. In other words, I would do the following: * Cut the introduction. Make "5 < False does not make sense" the sole motivation for types. * :type is a very useful skill and can stay as it is. * Ditto for function types, in particular multiple arguments. However, I think the openWindow example is not so good because it's actually a "pseudo" example; the real example would have to live in the IO monad. * Replace type signatures and type inference by two very short paragraphs that basically only say "This is what a type signature looks like and you should use it, too." "Type inference happens when you don't put a type signature there." Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com