[Haskell wikibook] Re: Truth values and a couple other things

[Heinrich Apfelmus]

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