Talk:Cookbook

Size and direction of page

Personally, it seems to me that this will be a very large and overwhelming page if it is filled out with all the items in the TOC. What about having it as a gathering page, pointing to other cookbook pages that are subs of this? BrettGiles 17:44, 22 February 2007 (UTC)

I think we should definitely do this, but after the page has grown big. As long as it's not needed, we should stick with one page. The user can now still easily scroll the page. User:chriseidhof.

As of now, the very short entries for the chapter give the page its very own charm. I like it very much and I think we should stick to that. It's more a cheatsheet than a cookbook, but who cares. -- Apfelmus 19:19, 25 February 2007 (UTC)

Makes sense. I like your thought of the page having "charm" :) BrettGiles 22:27, 26 February 2007 (UTC)

Do you guys know about this: http://pleac.sourceforge.net/ It seems to be abandoned and it seems the Haskell part didn't go that far, but it does show up on a google search. tanimoto 15:41, 24 April 2009 (UTC)

The haskell pleac part is a known disgrace and is not only old, but also uses horrible techniques like redefining the (.) function. It would likely be best if the pleac haskell entries be purged completely as they probably never have but certainly do not reflect current haskell best practices. --jethr0 20:30, 24 April 2009 (UTC)

Seems I have to retract that as somebody went to the trouble of fixing the mess that was pleac_haskell. I wouldn't guarantee that it's the finest haskell code ever, but at least it's no longer a total disaster. Maybe we can "borrow" some ideas from the pleac set of tasks. --jethr0 20:30, 24 April 2009 (UTC)

Actually, that was partly my point. I think it would be nice to see what we can reuse (if anything), then put a link to this Wiki entry so that people don't get confused. tanimoto 02:24, 25 April 2009 (UTC)

Focus on Haskell concepts as well as general tasks

I like the idea of selecting typical cookbook tasks and providing haskell code snippets. Also it might be useful to provide examples of certain haskell concepts that may not be related to a specific task, like "how to use Control.Monad", "how to use list comprehensions", "how to use STM" etc,. b7j0c

As long as the focus is on practical use, yes. I think we should not provide abstract examples, but concrete examples of a practical problem. This is a bit more difficult, but way more interesting for the end-user.

Somehow use a literate Haskell Approach

to make sure that code examples actually do what they are supposed to do (i.e. with sth. like docTest)

Also, I find separate pages for strings and lists superfluous. Let's have "Strings" link to "Lists" for the list functions and only describe character-specific cases for "Strings" (Unicode, upper/lowercasing, ...) --jethr0 13:17, 23 April 2009 (UTC)

--jethr0 20:08, 24 April 2009 (UTC)