[Haskell wikibook] Re: Splitting of "More on Datatypes"

[Daniel Mlot]

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 
"Datatype algebra"?

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
> later.
>
> 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
> lists.)
> * 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 
Trail.

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).

Regards,

Daniel Mlot