Talk:Haskell/Archive 3

Style and writing guides

 * Baron Schwartz, What is it like to write a technical book?. Contains useful tips for formulating things.

Talk Archives
/Archive 1/ (2004-02-21/2006-07-09) /Archive 2/ (2006-07-10/2007-01-07)

Move to Haskell wiki?
I'd like to start discussion as to whether we should move to the Haskell wiki.

Pros:
 * Closer to the hub of the Haskell community. Corollaries:
 * Easier for potential contributors to find us.
 * Easier to import content already on the Haskell wiki.
 * We could potentially change the code to the wiki or install new plugins etc if we wanted to. (Automate the 'next page', 'prev page' links? Etc.)

Cons:
 * The bother of letting everyone know we're moving
 * The bother of moving itself
 * I'm sure there's going to be some MediaWiki export/import tool somewhere, though.

DavidHouse 15:33, 6 January 2007 (UTC)


 * It would be tricky for sheer reason of licensing issues. For example, after bugging Hal all this time, I'm not sure I really want to bother him again to ask about the simple permissive license.  We've received a lot of contributions from a lot of users and would have to get everyone aboard.  For what it's worth, I personally agree to dual license my stuff under the simple permissive license.  I do agree that the Haskell syntax highlighting would be nice to have, though, as would having this be a Haskell.org product.  Then again, Wikibooks has a specific focus on creating textbooks, one single cohesive narrative.  The Haskell wiki is perhaps not the most appropriate venue for that, culturally.  Well... I guess that's a pretty weak argument on my part :-) -- Kowey 17:36, 6 January 2007 (UTC)
 * Could we have some arrangement whereby we have a subwiki of the Haskell wiki which is seperately licensed? Or maybe even a seperate wiki? I think the benefits of moving to haskell.org are worth it. DavidHouse 13:41, 8 January 2007 (UTC)
 * Hmm... I'm still quite hesitant about this. As an alternative, would it be possible to have a haskell.org address that automatically pops up here?  The user types in http://haskell.org/wikibook and winds up getting served by wikibooks?  What if we had Haskell markup? (Edit 18:13 - I meant what if we also had Haskell syntax highlighting on wikibooks?)  I get the feeling that moving would entail a certain amount of pain and confusion (for example, what will happen if we delete our content here and post a 'so long, folks!'  It seems the wikibooks people would just restore the content and we'd have two "competing" wikibooks, a bit like Spanish wikipedia and the other unofficial site from the early days.  (That being said, if we did move, sooner would be better than later, and I personally would migrate to the haskell.org version). -- Kowey 15:05, 8 January 2007 (UTC)


 * Note, I've posted a message on the Staff lounge asking for input from the wikibooks community at large. This might enrich the deliberations a bit, maybe get some useful insight into making these kinds of decisions.  -- Kowey 18:12, 8 January 2007 (UTC)

I'd prefer to keep stuff here; I'm a Wikipedia buff and I like the universality of the wikibooks/wikipedia world. Also, there's lots of good text in Wikipedia that can be imported here. If syntax highlighting is a big issue maybe we could add something to MediaWiki or write a preprocessor.

I think it is great here at Wikibooks. It has Haskell syntax highlighting actually. It can be linked to from other places. At any rate, the discussion above is quite dated by now and the book is doing well enough here. Backfromquadrangle (discuss • contribs) 04:34, 30 April 2014 (UTC)

wikibook at haskell dot org mailing list
See http://www.haskell.org/mailman/listinfo/wikibook -- Kowey 09:35, 29 January 2007 (UTC)

good Haskell
There may come a point when we will get to advertise this book within the wikibooks structure. I encourage any Haskell wikibookians to help put together this goodbook template. I think we need a nicer logo and snappier blurb. Any ideas? -- Kowey 10:57, 20 April 2007 (UTC)


 * To spark some logo discussion, I have put together a minimalistic test logo. Maybe this will start some other ideas as well -- Kowey 11:12, 20 April 2007 (UTC)

GHCi vs Hugs
I'm not sure whether it's a good idea to use GHCi instead of Hugs. The former is bulkier and installation may fail. But of course, GHCi offers  bindings on the command line which makes things easier to boot in the beginning. But once functions get big enough (which is as early as /Next Steps/), they are put in a file without preceeding  which takes some pain to explain. Wouldn't it be easier to deal only with Haskell script files and to go with the simple Hugs? -- apfe&lambda;mus 11:12, 27 February 2007 (UTC)


 * I'm using Hugs right now but the #haskell folks keep saying to switch to GHCi. I do wish for something like Python that allows typing stuff on the command line.  Sooner or later I hope we have some kind of IDE that has syntax highlighting, integrated documentation, and all that.  I've thought of a cute name for it ("HAskell Lazy IDE" aka "Halide") but am way too much of a Haskell newbie to attempt any implementation. 64.160.39.153 05:15, 4 March 2007 (UTC)


 * I use the Emacs haskell-mode myself. It's not too bad, but I understand Vim's haskell-mode and Visual Haskell (a plugin to Visual Studio) are even better as Haskell IDEs go. And if you really want to troubleshoot and code, there's always yi to hack on... --Gwern (contribs) 19:03, 4 March 2007 (UTC)


 * Well, after having learned some Haskell, GHCi automatically knocks the door to replace Hugs for it offers all the GHC extensions and runs GHC-compiled code. But in the beginning, Hugs is entirely fine and very fast in loading files. -- apfe&lambda;mus

To decide whether Hugs or GHCi should be the pillar of the "Beginner's track", it is perhaps a good idea to formalize the criteria involved. -- apfe&lambda;mus 09:57, 5 March 2007 (UTC)
 * 1) GHCi command-line is a   block with corresponding benefits such as   definitions. In contrast, Hugs can only evaluate expressions (but   statements are available, of course).
 * 2) Installation: being a bigger download and requiring bootstrapping (if installed from source), the GHC installation is more likely to fail than Hugs. In the end, Hugs is more lightweight.
 * 3) Hugs loads source files very quickly, GHCi takes some time.
 * 4) ... More criteria?

Teaching goals
To find a suitable running example (see below), it might be worth contemplating about the teaching goals of the four chapters. Here's an attempt. -- apfe&lambda;mus 11:12, 27 February 2007 (UTC)


 * "Haskell Basics"
 * Currently shows how Haskell looks like: what are variables, functions, types. Additionally, it says how to construct simple lists and tuples, tells something about IO and introduces a bit algebraic data types. Notably, it doesn't introduce recursion or how to deconstruct values (pattern matching, especially on lists).
 * I think that the current restriction to the "construction" ("transformation", with given primitive functions like ) of values is a good idea. This is indeed all what is needed to talk about variables, functions and types. To that extend, I think an adequate running example would have to be a combinator library that constructs or combines things, preferably interesting things like pictures, movies or sound. They key about functions, namely to abstract common patterns, can be exemplified by allowing the combinator library to fail, i.e. there are certain combinations that don't make sense. The reader would then be guided to abstract and build a combinator library on top that doesn't fail, i.e. only produces meaningful combinations. The juggling example would fit both goals.


 * "Elementary Haskell"
 * Currently introduces recursion, deconstruction, list processing and higher order functions.
 * So in a sense, this chapter is about the heart of computation itself, namely how to do a count of operations that depends on the input. The running example has to be in the same spirit, i.e. it should focus on recursion and repetition. Things like fractals and L-systems come to mind.


 * "Intermediate Haskell"
 * Currently introduces means to structure larger code (modules and type classes) as well as a full treatment of algebraic data types.
 * Algebraic data types finally introduce means to store and process custom data. Their recursive variants like binary trees lift recursion and "loops" like  to a new level. I think it would be worth treating trees (binary search trees, heaps, ...) in more depth, also because they are the key to fast data structures and algorithms. The class and module stuff is a bit orthogonal to that. Concerning classes, I think that automatic differentiation is an excellent showcase of their abilities.


 * "Monads"
 * Well, this chapter introduces Monads and monad transformers.
 * Monads serve two purposes: IO and structuring computations. Every programmer needs the first, but the second one is more a technique for the advanced track. I'm unsure on when to introduce IO. Hopefully, there will be a natural way to introduce it together with a running example.

At the end of the beginner's track, the reader should be able to write full Haskell programs. This also means that some stuff from the performance chapter has to be taught in the beginner's track. In order to enable the reader quite early to write full programs, one could declare some sections at the bottom of the chapters as optional.

Running example
Apfelmus was discussing with me on #haskell what our vision for the wikibook was. The basic idea that came out of this is that the wikibook should place a special emphasis on slow and friendly. Apfelmus suggested a very nice idea, which is to a single running example that we build up over the course of the beginners track, maybe even a game. What we could do is to look into bookshelves, go to our local libraries and plunder away, find great ideas for games or other programs we could build up over the course of the chapter. Also, once we know what game we want to build, we should consider writing the code for the IO stuff so that the user can just download it, plug his/her code in and get working straight away. Any ideas on the matter? -- Kowey 10:52, 27 January 2007 (UTC)

The trick about the running example should be that all introduced code and concepts are used by it and only it. So if the running example doesn't need a concept, either the concept has to wait until later or the example has to be changed to need the concept.

Here's the list so far:  Scissors, rocks and paper - an example from Bird and Wadler. This is not good as example running through the hole beginner's track, but it's excellent for explaining laziness. It's basically about representing a sequences of games by infinite lists. A strategy gets the sequence of its adversaries moves as an argument. data Move = Rock | Paper | Scissors type Strategy = [Move] -> [Move] play :: Strategy -> Strategy -> [Bool] Laziness and strictness come in when controlling cheating and determining who moves first.  Hunt the Wumpus - (Procyon) [good classic game; graph traversal problem]  2D Euclidean geometry software - While this is not a game and perhaps not of interest to programmers, it can be introced very early because its mathematical nature matches with the "functions & expressions"-approach.  Pool simulation - This is a game and relies on mathematical formulas. Of course, any simulation game is likely to have its functionality encoded in pure mathematical formulas suited for direct implementation.  Inspired by a possible example would be data base access with list comprehensions, maybe entitled "The essence of data base queries". A data base is just a list (set) of relations and queries are composed by,   and. This example would have the great benefit of being significant to the readers wanting "real world" stuff. We can directly point them to HaskellDB for the access of SQL data bases with list comprehensions. Admittedly, HaskellDB's interface is more complex than list comprehensions as those only capture the point "database = set of relations" but don't deal with the relations themselves. But we can beg the HaskellDB people to develop a simplified interface or develop one on our own.  A domain specific language for juggling. I don't juggle myself and I'm not sure whether this is interesting to everybody, but the patterns from Juggling Lab Animator are certainly fun to look at. The graphics enginge is supplied by us, but readers have to develop the combinators for producing non-failing juggling sequences.  An Adventure-style game. See. Seems to exercise a fair number of basic features while not being too terribly complex, and is copyright-free. --Gwern (contribs) 19:59, 1 March 2007 (UTC) </li><li> Functional data structures. Maybe these could be used in a simple multi-user hunt the wumpus game, so it would show the use of concurrency, the network library, and STM as well (the program would use multiple processes to handle simultaneous TCP connections from different users). 64.160.39.153 15:43, 4 March 2007 (UTC) </li><li> ... </li><li> Please continue this list! </li></ul>
 * Haskell Seminar, Beispiele zu Listen, Datenbanken (in german)
 * functional database queries

With some reordering it may even be feasible to have different examples for "Haskell Basics", "Elementary Haskell" and "Intermediate Haskell".

Chapter organization
While names like "Wider Theory" or "Haskell Performance" do what they should, I think they're a bit dull. I'd really like to have shiny names, like "Fun with Types". Here are some proposals. The intended contents is also noted. Besides, every chapter could get an introductory section accessible via the TOC. The names of these subchapters can be picked to match the chapters intensions to allow for funnier chapter names. Apfelmus 12:39, 21 January 2007 (UTC)


 * "Advanced Haskell"
 * Currently a refuge for stuff that doesn't fit anywhere else. Possible independence movements:
 * * "The Awkward Squad" (Concurrency, IO, Exceptions, operational semantics)


 * "Wider theory"
 * = "Program correctness", "Formal program manipulation" , "To denote or not to denote", "Meaning, the Meany", "Devoting to Denotation"
 * intro = "Why does my program work?", "What does my program do?", "Help, my program doesn't work!" (sneaky, because the chapter should not cover debugging)
 * Intended to contain methods to reason about program semantics/correctnes and their adherence to a specification. Also includes the systematic derivation of programs from their specification. In a wider sense, relations to logic and dependent types might go here, too. I'm not sure what to do with category theory, but it certainly is a framework for denotational semantics.


 * "Fun With Types"
 * = "Types: reloaded", "Types: extended"
 * intro =
 * Currently describes the manifold extensions to Haskell's type system. I'm not sure, but I think that in the long term, they need a (separate?) chapter showing how to put them to good use, i.e. "Program/Library design".


 * "Haskell Performance"
 * = "Haskell in Space and Time", "Space and Time", "Running Haskell", "Haskell on the Machine"
 * intro = "Help, my program is slow!"
 * Contains everything related to the actual execution of Haskell programs (execution times, how to decrease them, memory, evaluation order, ...)

In general
My contributions to the wikibook mostly range over the more advanced topics. My vision for the wikibook is a place with tutorials right from the very beginning through to the most advanced Haskell. There is currently no centralised area where advanced topics are taught, with the possible exception of the Haskell wiki(s). Still, I think the advanced track could become a really good collection of tutorials, which are well organised, polished (exercises/images etc.) and have good coverage of the advanced topics. I think Haskell/Category theory was our first big success; I'd love to see more articles with this flavour. DavidHouse 11:15, 27 January 2007 (UTC)


 * Haskell/Denotational semantics, although not as polished as the CT article, is another 'big success' article; I'd forgotten about that! DavidHouse 11:20, 27 January 2007 (UTC)

Haskell Education Tools
We need tool support for explaining Haskell (à la LOGO), concocting wikibook exercises and solutions (graph reduction printer) etc.

Expanding expressions with free variables
Reflecting Haskell expressions. Really cool, type an expression in the interpreter and have it printed out:

> foldr f x [1..5] f 1 (f 2 (f 3 (f 4 (f 5 x))))

Doesn't work for everything of course. I'll ask Twan whether he can put it on hackage so that we can reference it in the wikibook.

Graph reduction tracer
None existent yet.

"Haskell Best Practices"
Hi,

I have just started learning Haskell. I'm reading this book and YAHT and make small edits as a way to learn.

My experience is mostly with Perl and Java, so i am used to different patterns of code layout. For example, in Perl I would write a list as (1, 2, 3), with a space after each comma. That's what most Perl style guides say (such as perlstyle).

But in Haskell it may be different. For example, GHCi says

Prelude> let strings = ["here", "are", "some", "strings"] Prelude> strings ["here","are","some","strings"]

I also looked through the source code of Pugs, and sometimes there is a space after comma, and sometimes it is not; either the Pugs developers are just inconsistent, or they do have a convention, but I don't know enough Haskell to understand it.

So my question is: What is the preferred way to write literal lists?

More generally: Is there a Haskell style guide, such as Code Conventions for the Java Programming Language, perlstyle, Perl Best Practices?

Thanks in advance. --Amir E. Aharoni 14:13, 8 June 2007 (UTC)


 * Hey there, and thanks for your edits! ( although you might want to note that some of the s's, for example, "specialised" are an attempt at International English rather than spelling errors, as far as I know :-D ). I don't think there is any particular convention or written best practices on this.  It probably depends on context.  You could ask on the mailing lists; Haskellers tend not to be flame warriors, so there isn't much risk (I hope!) of this turning into one of those endless discussions about nothing.  -- Kowey 14:29, 8 June 2007 (UTC)


 * -ise vs. -ize should also be a matter of a book-wide convention :)
 * I fixed them, because I mostly use Firefox for spelling, and my Firefox installation uses the American standard. I think that I've seen some z's here too, so I took the lazy path to consistency.
 * And while we're on it - Thanks for your efforts about syntax highlighting. I thought of doing the job of requesting support for GeSHi and Haskell in Wikipedia/Wikibooks, but then I saw that you've already done everything.
 * Since you seem to be a bit more experienced than I am in these matters, I have another question. Currently if I try to write, it is rendered as a Big Red Error that doesn't show any code. I think that it would be better to display the source in the default black color with a small warning saying that the language is not supported. This way, when language support is added, the warning will go away and the coloring with just start working. Am I the first person to propose this? --Amir E. Aharoni 15:09, 8 June 2007 (UTC)


 * Yep. Agree about the book-wide convention.  As for GeSHi, you might want to post a bug report on the mediawiki bugzilla, see what others think -- Kowey 17:54, 8 June 2007 (UTC)


 * I entered a feature request in Bugzilla: 10201 Allow showing code in an unsupported language with a warning. Come on and vote for it if you like it :) --Amir E. Aharoni 18:27, 8 June 2007 (UTC)

Anyone else editing
Are there any other Wikians interested in keeping this book alive, or are my contributions a waste of time. MacNala (talk) 09:16, 27 February 2009 (UTC)


 * First, hello MacNala and welcome to the Haskell wikibook. :-) It's not exactly the most active project, but alive and useful. Contributors are always welcome!
 * -- apfe&lambda;mus 09:41, 28 February 2009 (UTC)


 * Keep also in mind that contributions are not for other contributors, but current and future readers (though the two often overlap). :-) Happy editing. --Swift (talk) 14:32, 1 March 2009 (UTC)

Hello From Germany
I wrote some small, unimportant and unprecise tutorial on Haskell on the German Wikibooks is de:Haskell. Yours Dirk Hünniger
 * Looks great. :-D apfe&lambda;mus 08:44, 21 July 2009 (UTC)

Orphaned pages
The following pages are not linked to and should be marked with if no longer needed, linked to, or merged into another page and marked with. -- Adrignola talk contribs 18:45, 2 August 2009 (UTC)
 * Haskell/Kinds
 * Haskell/YAHT/Errata


 * Thanks, have been linked to.
 * -- apfe&lambda;mus 10:01, 3 August 2009 (UTC)

Hi all, I'm a contributing newbie!
Hello everybody! I started to learn Haskell with this book and I am devouring it, doing all exercises in each chapter and enjoying it a lot. The last topic I studied was Haskell/More about lists. While reading it, I took issue with the List comprehensions part (reasons explained in the talk page of that topic), and decided I could improve it with some substantial refactoring. Since I have literally four days of experience with Haskell, however, it would be very useful for everyone if more experienced Haskellers could review my contributions, so I kindly invite you to head over there. By the way, I noticed someone already fixed a silly mistake in one of the code snippets I wrote last night. That is very encouraging :) --Duplode (talk) 18:39, 27 April 2010 (UTC)


 * Hello Duplode, welcome to the Haskell wikibook! :-)
 * Thanks a lot for your contributions! I'll have a look at your edits to the list comprehensions; will take a while, though. Meanwhile, don't hesitate to change more things; the wikibook sure needs some polish at times.
 * Don't miss out the other cool places for learning Haskell, like the #haskell IRC channel and the haskell-cafe@haskell.org and beginners@haskell.org mailing lists.
 * -- apfe&lambda;mus 18:38, 28 April 2010 (UTC)


 * Thanks Apfelmus, I do intend to continue contributing as I advance through the book (last one was an attempt to add a bit more of context to Haskell/Type declarations, BTW). And I will surely check the mailing lists... --Duplode (talk) 05:58, 29 April 2010 (UTC)

About Elementary Haskell...
So in the end I was bitten by the bug of Wiki editing and reworked pretty much all of the Elementary Haskell chapter. I was careful not to bite more than I can chew, so I avoided adding unfounded personal inferences as much as possible. Instead, I focused on rearranging modules, to eliminate forward references and make the chapter feel like a unified whole, and on providing more verbose discussions on important concepts which were just glossed over. The really big changes were mostly: Now my refactoring is up for the inspection of you specialists; hopefully I have done a good job. --Duplode (talk) 17:17, 3 May 2010 (UTC)
 * Type declarations (in the Haskell basics module) is almost twice as long. By spending more time discussing constructors in their "natural environment" I believe it becomes easier to make the link to pattern matching when the time comes.
 * By the same token, the Pattern matching module now takes advantage of the build-up in previous modules to provide a less dry discussion (someone in the talk page mentioned feeling "thrown in the deep end" with the previous version, and I felt pretty much the same when reading it for the first time). Also, the unnecessary forward references were weeded out or transferred to More about functions (except for one of the examples using Maybe, which, now accompanied by the presentation of the Just / Nothing constructors, be used as a less "boring" example for both pattern matching and datatype definitions). Finally, I added a section on pattern matching against literal values for the sake of completeness.
 * While the rewrites of More about lists and List processing weren't as extensive, the ordering of the sections is very different: More about lists provides the introductory general discussions and explains map (which was originally on List processing); List processing follows immediately by covering folds, scans, filtering and comprehensions. This arrangement solves the circular dependencies that used to happen there while not making any of the modules overtly long (and therefore tiring).


 * I've finally had a look at your work; good job! It's definitely a much needed improvement.
 * Just for reference, here a hyperlink to the mailing list where you've initiated the discussion on plans for the future.
 * -- apfe&lambda;mus 08:33, 8 May 2010 (UTC)

Mailing list revival and new projects
As Apfelmus mentioned above, we are having some discussions in the mailing list about ways to improve the book. The ideas for improving usability are not shying away from large-scale reorganizations, and include:


 * A switch to a less linear and more modular chapter organization paradigm, specially for the advanced modules, supported by convenience resources such as prerequisite tracking and study guides;


 * A restructuring of the Beginner's Track, aiming towards having the individual chapters ("Haskell Basics", "Intermediate Haskell", etc.) with clearly defined roles and allowing to separate fundamental language features from syntactic sugar.


 * The elaboration of a lightweight "cheat sheet" for essential Prelude functions, in order to provide newbies with a handy reference while keeping the fundamentally conceptual discussions on the main track of the book unspoiled by systematic standard library study.

To help with the discussions on the first two proposals I created Haskell/List of topics, which is intended to be used as a brainstorming sandbox. Experiments on cheat sheet designs will hopefully get underway soon.

All interested parties are invited to join the discussions and/or contribute, both here and at the mailing list. --Duplode (talk) 00:57, 13 May 2010 (UTC)

Examples
Hi,

I'm a newcomer to Haskell and so far this book helped me a lot in learning it (I'm not finished yet). So I decided maybe I could help it a bit. While reading the pages I've come across some which use "Examples" to display source code, like this:

Personally I find this double indentation and the example section distracting and as all source code in this book is an "example" I would prefer to just set it like this (which is also heavily used):

What do you think? Would it be okay if I remove the "HaskellExample"s and convert it to normal source code? --Rudis (talk) 11:25, 28 June 2010 (UTC)


 * Hello Rudis, welcome to the Haskell wikibook. :-)
 * The example markup is rather inconsistent. I think there is a small semantic difference between the example boxes and the source blocks though, namely that the former can be copy&pasted into new .hs file and are guaranteed to compile or something like that.
 * I suggest that you keep the template calls as they are but adjust the Template:HaskellExample instead to yield less obtrusive layout?
 * While we're at it, there's also the issue of "Haskell source code" vs "GHCi transcript", it would be nice if we could distinguish them with different colors like the GHC user's manual does.
 * -- apfe&lambda;mus 09:29, 29 June 2010 (UTC)


 * Hi Apfelmus. You're right, there is a difference between both, I didn't think of that. What do you think of this possible update for Template:HaskellExample:

<div style="background: ; margin: 1em 3em"> Example: Hello! What is your name?


 * I think a small indentation to separate it from "normal" code is a good idea. The source lang="haskell" can't be part of the example template because some examples also display normal text. Maybe a new template HaskellSourceExample could be added which contains the source lang="haskell" so it doesn't need to be duplicated in each example.)
 * Adding a template for GHCi code would be a good idea. I'm not sure how it should be colored though, but that could be decided later. Should I add create Template:HaskellGHCi which will display GHCi code?
 * Maybe we should add a section in "Getting set up" which explains the style rules used in the book (source code, examples, ghci transcript). What do you think? --Rudis (talk) 19:19, 30 June 2010 (UTC)
 * PS: Would it be possible to update the PDF version of the book? I would upload a new version myself, but I don't know how to do it. --Rudis (talk) 19:24, 30 June 2010 (UTC)


 * Looks good. Maybe add some sort of box around the "Example: Hello.." as well, so that it's "visually glued" to the box containing the code? (Otherwise, it might look confusing in the regular text. But maybe the small indentation already solves that.)
 * Sure, go ahead with the GHCi boxes. :-) You can test them out in the first couple of chapters.
 * Writing down our use of markup and templates is a good idea! I propose the name "Style and implementation guide"?
 * I have no clue how to update the PDF version or how it was created in the first place, I'm afraid.
 * -- apfe&lambda;mus 08:20, 1 July 2010 (UTC)


 * Good, I updated Template:HaskellExample. I think a box around "Example:" isn't necessary, but if you like a box better, just change it. I also tried adding Template:HaskellSourceExample as "shortcut" for &lt;source lang="haskell"&gt;, but it didn't work. Do you have any idea why the is not expanded in &lt;source&gt; (example in User:Rudis/Sandbox)? The same problem occurs with Template:HaskellGHCi ( is not expanded in &lt;pre&gt;). Any idea how this could still be done?
 * Sounds good, where should we put it? Before "Getting set up" in Haskell Basics?
 * I already "generated" the PDF version (it's just print to PDF in Firefox) but I don't know how to upload the resulting PDF to wikibooks. I thought "Edit" on the page would do it, but this doesn't work. --Rudis (talk) 19:58, 1 July 2010 (UTC)


 * Fixed the template and the template calls. It's important to use named parameters in the style of  when the argument contains "=".
 * "Internal" stuff used to be in Haskell, but you can put it in the Haskell section.
 * I have no idea. I think the PDFs are generated by wikibooks, though. You may want to look around in the Help section or ask around on the help desk.
 * -- apfe&lambda;mus 06:56, 3 July 2010 (UTC)


 * Thank you very much. I totally overlooked that in the Wikipedia template help page; works perfectly. I updated the templates a little and added some documentation (also to the other templates); added a new template Template:HaskellGHCiExample and started using them in the first pages. Please tell me if there's anything which could be improved regarding the templates (or my edits).
 * Regarding the PDF, I will have a look. Thanks. --Rudis (talk) 13:18, 3 July 2010 (UTC)


 * One (hopefully) last question regarding templates: Is there a way to make the following code work in templates without quoting the | as | (taken from Haskell/Truth_values)?


 * Thanks. --Rudis (talk) 13:32, 3 July 2010 (UTC)


 * Gah! Judging from w:Help:Templates, it seems like there's not way to avoid that. :-( I guess we need to go back to using  tags in the second parameter of the template.
 * (Formatting is a pain on wikibooks. Sometimes, I think we should host a custom Haskell wiki like Gitit and move everything there. :-/)
 * -- apfe&lambda;mus 08:21, 4 July 2010 (UTC)
 * Should I remove the Template:HaskellSourceExample (or just discourage its usage in the documentation)? Or do we want to escape  with  ? I think Template:HaskellGHCi and Template:HaskellGHCiExample are fine (I think   is used seldom with them). --Rudis (talk) 20:30, 5 July 2010 (UTC)

--あるうぃんす (discuss • contribs) 06:48, 1 June 2013 (UTC)
 * I'd keep the template but remove the automatic source markup; i.e. any use of the template has to add explicit " appearing as " ". Found at p.42 / 597 of the pdf (\thepage is 30) and p.44 / 597 (\thepage : 32).
 * Some codes in the Example s are typeset in roman, not \texttt or such. Such as
 * p.39 / 597 (\thepage : 27, section 5.2.1)
 * p.42 (\thepage : 30, section 5.3.2). Mischievous &lt;code&gt; and &lt;code/&gt; is also printed.
 * p.50 (\thepage : 38, section 6.1.1)
 * p.52 (\thepage : 40, section 6.1.3)
 * p.55 (\thepage : 43, section 6.3 ). Mischievous code tag.
 * p.57 (\thepage : 45, section 6.4 )

2014-12-04 anon awesome! One bug: in the bookmarks (as edited with jpdfbookmarks), every extra formatted word is replaced with some url.

Reorganizing the Monads chapter
As usual for "bold" large-scale changes, I will leave a note about today's reshuffling of the Monads part of the Beginner's track. Putting it briefly, I have:
 * Incorporated the existing subpages of Haskell/Understanding monads (Maybe, IO, State, List) into the main structure of the book (ToC, nav templates, print version);
 * Taken the (as of 2012) largely misnamed, redundant and out-of-sync Haskell/Advanced monads out of the book structure (I don't think it should be deleted though duet to the issue of attributions - a history merge with some of the Understanding monads pages would be too messy);
 * Diluted most of the non-redundant material in Advanced monads with the Understanding monads subpages (there is some pertinent stuff in the State section that might be worth transferring as well).

In another note, I also removed the Haskell/Working with lists red link (see Haskell/To do for extra considerations on that); and, with it, the reorganization warning added nearly two years ago... --Duplode (discuss • contribs) 09:24, 1 May 2012 (UTC)

"Practical Haskell" vs "Haskell in Practice"
The Overview section mentions a book section called "Practical Haskell" section, and that book section is also mentioned in some other pages. Yet this page does not list a "Practical Haskell" section. Instead, there's a "Haskell in Practice". This is probably meant to be the same thing, but given the proliferation of books and tutorials with different but similar names, this lack of agreement is confusing.


 * Now fixed (standardized as "Haskell in Practice"). Thanks! Duplode (discuss • contribs) 04:07, 27 July 2013 (UTC)

Feedback
Hi, I'm relatively new here, read the book a few months ago, struggled but learned a lot. I'm still new to Haskell and programming in general. I've decided to work on learning in part by improving the book. I'm doing a general revision of every page, mostly cleaning up the wordings and fixing confusing things. At the time of this comment, '''almost all the discussion below is very dated (and mostly outdated). The book has been substantially improved since these comments were made.''' I think it is nice to have a way to discuss plans for the overall book, but it makes most sense for people to just go ahead and clean up details on specific pages as needed. The discussion pages for each chapter are appropriate. It's a bit too hard to follow outdated general discussion here. Overall, I think the book is excellent, although there is always room for improvement. Just remember that it happens where people fix the book itself without cleaning up the discussion comments, so they get outdated. Backfromquadrangle (discuss • contribs) 04:34, 30 April 2014 (UTC)

Lazy
Hi! I found this book because it was featured today. I just found it odd that in the first sentence in the blurb it calls the language a "lazy functional programming language", without clarifying what lazy means in programming circles in the blurb. Because the word lazy has a really negative connotation, I think it might be a good idea to clarify in the blurb. Thanks for reading! JonathanHopeThisIsUnique (discuss • contribs) 21:50, 12 September 2014 (UTC)