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