[Haskell wikibook] Next steps (both literally and the module)

[Daniel Mlot]

On 06/03/2010 04:31 PM, Heinrich Apfelmus wrote:
> Daniel Mlot wrote:
>
>> 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.
>

I just created the proposed "Type basics II" module. The changes I did 
so far are sort of in between my approach and yours (not that they were 
really in conflict to begin with, but anyway), as I will now explain...

> In other words, I would do the following:
>
> * Cut the introduction. Make  "5<  False  does not make sense" the sole
> motivation for types.

While I agree that the introduction does need streamlining, I am not so 
sure about eliminating it completely, as it can be useful for making it 
easier for readers to amalgamate all the other discussions in this part 
of the book around the key conceptual issue - that types are a way of 
incorporating meaning into values. That is why I kind of like the 
abstract "real world" example, even if in its current form it is a bit 
too overcooked to drive the point home.

> * :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.

Agree about openWindow; it would probably be better if we could find a 
more workable real life example. On the other hand, given that the 
reader is not supposed to know or understand what the types actually are 
anyway, just putting "IO Window" in the signature would be no worse 
than, say, "Foobar" or "Hippogriff" :)

> * 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."
>

I shortened (though not that much) the final sections so that they could 
fit into the first "Type basics". The detailed rundown of an inference 
example was simplified (so that we are not forced to explain 
polymorphism) and the examples and exercises with forward references 
were eliminated (by the way, I am keeping a copy of deleted sections in 
http://en.wikibooks.org/wiki/User:Duplode/Haskell_leftovers for 
reference and to make eventual reincorporation of materials easier).

As for Type basics II, as of now it is a lightweight discussion on how 
the type system handles numbers, written in a style similar to that of 
Truth values. Typeclasses are introduced, focusing on their implications 
for polymorphism. Some essential "concrete" facilities for number 
manipulation are presented, but for now I am assuming that systematic 
presentation of, say, arithmetic operators will be deferred to the cheat 
sheet modules or similar places.

Finally, a question about Next Steps the module. Do you see a place for 
it in the overall scheme of things? My question is largely motivated by 
the fact I am finding it rather difficult to picture a way to 
incorporate pattern matching into the "soft", largely conceptual modules 
about the type system (I am counting "Truth values" and "Lists and 
tuples" among these) without breaking their flow. That leads me to 
consider introducing piece-wise function definitions or even (x:xs) and 
(x,y) in a separate context. The function composition operator is 
another potentially useful thing in "Next Steps" (because it fits well 
with the idea of stimulating creative usage of Prelude functions) that 
would be difficult to move to an earlier point of the book. That case is 
less serious, though, as there is the option of just moving it to "More 
on Functions".

Regards,
Daniel Mlot