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