Talk:Haskell

From Wikibooks, the open-content textbooks collection

Jump to: navigation, search

Contents

[edit] Style and writing guides


[edit] The front page

If Haskell is unique for two reasons (at least)... one of them has got to be laziness, don't you think?

Hmm... I guess so. Would a purely functional language have to be lazy? If not, then, yeah :-) [I say this in total ignorance] -- Kowey (talk) 21:20, 16 June 2008 (UTC)
Pure = no side effects. A lazy language has to be pure, but a pure language need not be lazy (imagine ML with monads). Still, non-strictness is an outstanding property of Haskell. -- apfeλmus 09:44, 17 June 2008 (UTC)

[edit] Technical organization

[edit] Talk Archives

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

[edit] Move to Haskell wiki?

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

Pros:

  • Haskell syntax highlighting!
  • Closer to the hub of the Haskell community. Corollaries:
    • Easier for newbies to find us.
    • 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 Wikibooks: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.

[edit] wikibook at haskell dot org mailing list

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

[edit] 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)


Haskell (download)

 Haskell is a functional programming language with a state of the art type system. This book will introduce you to computer programming with our language of choice. It is friendly enough for the newest programmers, but deep and challenging enough for the most experienced. Come stretch your mind with us!

[edit] Chapter organization & content

[edit] Beginner's track

[edit] 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 let 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 let 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λ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λ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λmus 09:57, 5 March 2007 (UTC)

  1. GHCi command-line is a do block with corresponding benefits such as let definitions. In contrast, Hugs can only evaluate expressions (but let .. in 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 leightweight.
  3. Hugs loads source files very quickly, GHCi takes some time.
  4. ... More criteria?

[edit] 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λ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 fold to a new level. I think ot would be worth treating trees (binary search treess, heaps, ...) in more depth, also because they are the key to fast data structrues 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.

[edit] 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 map, filter and concatMap. 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 [1]. 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)
  • 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)
  • ...
  • Please continue this list!

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

[edit] Advanced track

[edit] 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, ...)

[edit] 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)

[edit] Haskell in Practice

[edit] Haskell Education Tools

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

[edit] 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.

[edit] Graph reduction tracer

None existent yet.


[edit] "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 <source lang="haskell">SOME CODE</source>, 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)
Retrieved from "http://en.wikibooks.org/wiki/Talk:Haskell"
Personal tools
Create a book