[Haskell wikibook] Re: Splitting of "More on Datatypes"
duplode_1 at yahoo.com.br
Tue May 11 20:13:35 EDT 2010
On 05/10/2010 10:51 AM, Heinrich Apfelmus wrote:
> I concur. In my opinion, the second part about generalized folds and
> maps does not even belong to the beginner's track; it should be moved to
> a chapter "Generic Programming" in the "Fun With Types" section. (Some
> prefer the name "Datatype algebra" for that currently missing chapter,
> but the standard name is "Generic Programming". By the way, it's
> prerequisite to the second part of the "Zippers" chapter.)
In that case, the part about "Trees" would stay more or less where it is
now, while the final sections would be moved forward to "Fun With
Types/Generic Programming", which would replace the existing red link to
Anyway, I intend to carry out a provisional splitting in two parts -
"More on Datatypes" and "Other data structures" (the weak unspecific
name is intended to be provisional) so that restructuring of the first
part is easier to carry out. Before doing that, however, I must ensure I
understand how page moving in Wikibooks works...
(By the way, I noticed the missing prerequisite on "Zippers", and would
in normal circumstances have got seriously confused by it - but dataype
derivatives struck me as such an awesome concept I didn't bother)
> Yep, I moved it because it seems silly to discuss data types but then
> defer the discussion of how to use them (= pattern matching) until much
> My vision for the 'Haskell Basics' section is to present a minimal
> subset of the Haskell syntax and language that still enables people to
> write pretty much any program they want. This way, readers don't have to
> wade through all the syntactic variety before getting to the core concepts.
> In particular, I propose the following subset:
> * guards, but no if .. then .. else
> * where clauses for local definitions, but no let
> * Lists, list comprehensions and many Prelude functions involving lists;
> but no pattern matching. (Not sure about omitting pattern matching on
> lists yet, but the idea is to encourage "whole-meal" programming with
> * Standard primitive types
> Int, Double, Char, String, (,), ->
> and polymorphism.
> * Type synonyms to encourage abstraction; but no user-defined data
> types, tuples will have to serve.
> * Type classes need to be mentioned because of error messages due to the
> overloading of numeric literals. Also, readers need the show function.
> * Very simple IO, do syntax:
> reading and writing files, interacting on the terminal
A restructuring like this would help to make the book to have better
internal consistency. For instance, reworking the way local definitions
conditionals are presented in the beginning by presenting just the
simpler possibilities would help with finding a proper use for modules
like "Control structures" or "More on functions", which as of now are
rather annoying because they feel detached from the context of the rest
of the book. I also think that the absence of any discussion on how
numeric types/classes work is a big problem, and basic reading and
writing from files is probably too useful to leave out.
I have a few doubts about your subset, though. Firstly, even if you are
probably thinking of a full-scale reassembling of the modules and
chapters that might nullify my concerns, I wonder if a minimal subset
which "enables people to write pretty much any program they want"
wouldn't cause too much material to be placed in a single book
segment/chapter, in detriment of the other chapters in the Beginner's
Also, with regards to the list-related material, pattern matching looks
like such an integral part of day-to-day Haskell usage it seems natural
to present initial examples without getting into details of how it
actually works. Of course this is just an impression from a newbie
haskeller, and that there may be conceptual problems I might not be
giving due weight to - for instance, it could well be that many people,
after seeing pattern matching in action without a proper explanation,
think it is some kind of magic and develop wrong ideas about how the
language works (such a situation could make a good reason for
stimulating "whole-meal programming").
Finally, a note about exploration of "many Prelude functions involving
lists". One of the things I enjoyed about the initial modules of the
book was how it presented the essential concepts with minimal "clutter"
of alternative syntax and, specially, systematic study of the standard
library. I realize that this slower, less practical style probably does
not work for everyone, and is occasionally overdone (for instance, by
waiting an eternity to introduce type classes), but still I feel such an
approach has merit - and furthermore, it would help to distinguish our
basic modules from, say, LYAH. There are a few subtler ways of working
with Prelude in the book, which is already done semi-intentionally in
some parts of the book, such as slipping new Prelude functions in
examples and exercises and stimulating readers to be curious (for
instance, by using GHCi to immediately query the type signature of every
and each unknown function they happen to meet).
More information about the Wikibook