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

[Daniel Mlot]

On 05/12/2010 05:53 AM, Heinrich Apfelmus wrote:
>
> That said, I envision a separation like this:
>
> * Haskell Basics       =>  write any functionality
> * Elementary Haskell   =>  write idiomatic Haskell code, full syntax
> * Intermediate Haskell =>  write libraries, i.e. modules and type classes
>
> So, Haskell Basics is really just a subset of what a full Haskell
> programmer should know, but it's enough to write small programs in a
> rather limited style that can nonetheless express pretty much anything.
>
> For example, I imagine that Haskell Basics teaches only
>
>     squares n = map square [1..n]
>         where
>         square x = x ^ 2
>
> while a full Haskell programmer would write this as
>
>     squares n = map (^2) [1..n]
>

There is one very important issue which your proposal accounts for. As 
of now, that there no clear rationale which justifies the division 
between Basics, Elementary and Intermediate. For that reason, I don't 
believe the separation is really useful to readers. Furthermore, it is 
confusing to have "Elementary Haskell" as the second segment of the 
book, and a restructuring would be a nice opportunity to address such 
problems with less generic names.

As for the number of segments, I guess that as long as the underlying 
logic is clear it is just a convenience decision - for instance, if 
Haskell Basics ends up with, say, 15 modules it could be handy to make 
an arbitrary pt. 1 / pt. 2 division.

I will make an exercise and try to display an interpretation of your 
suggestions using the "List of topics" I created in the Wikibook. By the 
way: I guess that both "More about lists" and "List processing" would go 
in their entirety to the new "Basics" (except for the casual "teaser" 
about currying and partial function application nested in "More about 
lists")

>
> There's nothing wrong with pattern matching. If anything, the problem is
> this: With pattern matching and recursion, you can define any function
> on lists. But then, it is also tempting to do exactly that and forgo the
> vocabulary of functions offered in the Prelude, at the detriment of good
> Haskell style.
>
> [...]
>
> Okay, I created this example for this very purpose, but it does happen
> in practice:
>
>      "Memory usage problem"
>      http://thread.gmane.org/gmane.comp.lang.haskell.beginners/3842
>      (read the original question and my reply)
>

That thread drives the point quite clearly, and I must admit I can, 
based on my newbie experiences, relate to this tendency of defining 
everything explicitly due to inexperience or merely to the desire of 
playing with the language. Guess that's why someone put a funny-looking 
"Don't get TOO excited about recursion" header in the "Recursion" module :-)

>
> Daniel Mlot wrote:
>> 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.
>>
>> [...]
>
> In the light of the above, conveying a good grasp on the vocabulary is
> necessary, but I agree that a diligent study of standard libraries is
> not necessarily a good idea. The thing is that the reader can only
> memorize so many things at once, and it would be a waste to squander
> this on uninteresting syntactic variations and library functions that he
> doesn't need right now.
>
> I imagine the best way to solve this is to present a subset of the
> Prelude in style of a "cheat sheet", i.e. as documentation that the
> reader should consult whenever he needs new vocabulary.
>
> Astonishingly, such a thing does not exist yet, at least not how I
> imagine it. There is
>
> * Bernie Pope - A Tour of the Haskell Prelude
> * GHC doc - Prelude
>
> but the former has no thematic categories like the latter while the
> latter does not restrict itself to the Haskell Basics subset. I've given
> some private lessons recently and I was surprised to find that it's
> really tricky to find the  show  function if you only know that you're
> looking for something that will convert stuff into a  String .
>

Full agreement here. A cheat sheet should really be a top priority, 
specially if there is nothing like what we are envisioning available 
elsewhere.

To your considerations on how the cheat sheet should be a 
"documentation" module detached from the main flow of the book, how it 
should restrict itself to the essentials and how it should be organized 
by topics I would only add a proposal on presentation. Essentially, I 
believe the "clutter" applies both ways - at the same time I don't want 
to be bothered by systematic discussion of Prelude while I'm trying to 
grasp the concepts I would like to be able to use the cheat sheet as 
expediently as possible, without having to wade through vague 
discussions or minute details if I don't want to, just picking the tool 
I need and stealing away back to the book or to my code. For that 
reason, a format like the one of "A Tour of the Haskell Prelude" is 
truly inadequate for what we intend. Instead, I believe the cheat sheet 
pages should have two parts:

* A very straight-to-the-point table, located at the very beginning of 
the pages, which presented the functions, type signatures and one-line 
descriptions, (ideally) in a way that no more than a quick glance should 
be needed for locating the function you need.

* Following the table, a section with more detailed comments on each of 
the functions. The subsections on each function would be linked from the 
table for convenience. This separation would also have the advantage of 
not forcing us to write the extra comments and notes in some strict 
format, as the necessary restrictions would already have been put in 
practice in the table.

I will help kickstarting the cheat sheet with formatting experiments and 
some initial examples, even if I don't think I can go too far on my own 
due to lack of Prelude experience.

Regards,

Daniel Mlot