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)
- I've split up the page into subpages now, since saving and restructuring the content has become a pain. --Lenny222 10:54, 23 April 2009 (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.
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)
- You are right. We should "unify Strings and Lists", but in a way that people new to Haskell will find solutions to common programing problems. I am convinced that Strings := Lists don't come natural to most. So I am not yet sure how to do that. I also don't know how to mix literate Haskell with Wikimedia. --Lenny222 13:35, 23 April 2009 (UTC)
--jethr0 20:08, 24 April 2009 (UTC)