Talk:Haskell/Archive 1

It might be useful if we asked people on the Haskell Wiki if we could use their material. http://www.haskell.org/hawiki/. If i'm not mistaken, there's no expicit license, so we'll either have to contact editors individually or find some sort of collective policy, or make some sort of announcment. -- Kowey 11:19, 21 Feb 2004 (UTC)


 * anyway, i've put put a page here http://www.haskell.org/hawiki/UsingHaskellWikiMaterial


 * Yippee! The new Haskell wiki has a simple permissive license. I guess this means anything that goes on the new wiki can go here.  -- Kowey 09:56, 14 January 2006 (UTC)

I've also got permission from Jeff Newburn to rip material from his "All about monads" tutorial (which is the one thing that enabled me to understand the damn things!). -- Paul Johnson 19:05, 2 Jan 2006 (GMT)


 * Cool! We could also mix and match with stuff from my tutorial, Of Monads and Spacesuits, not to self-plug or anything :-) -- Kowey 19:47, 2 January 2006 (UTC)

Hmmm. I've had a look, and I like the idea. However having space stations processing astronauts does seem a bit of a stretch. How about having machines processing bits of nuclear waste. Each machine must always ensure that the waste leaves it in a sealed conatiner. This also allows us to have a machine that takes several containers of material and puts the contents into a single container, which is what sequence does (the thought of several astronauts in a spacesuit, while comic, does stretch things a bit far I think). -- Paul Johnson 23:13, 3 Jan 2006 (GMT)


 * Heh. :-) I tend to think of multiple astronauts in a suit as just being in a space shuttle.  Maybe I could say that explicitly to make it easier to swallow.  As for nuclear waste, we should try it!  I tend to believe that we've got grab a whole of different metaphors and flesh them completely out until one of them fits nicely enough or until we cover enough readers' mental models.  The Jeff Newburn assembly line and tray metaphor might also work.  I guess we're all just instances of Cale Gibbard's monad as container idea.  Whatever we do, I'd prefer that the metaphor have nothing to do whatsover with computers.  See below for more thoughts -- Kowey 20:27, 4 January 2006 (UTC)

Monadic metaphors
Nuclear waste. How should we go about explaining the state monad? What would you is a good way to represent the lambda (ticket) in a nuclear waste metaphor? -- Kowey 20:27, 4 January 2006 (UTC)


 * I would say that each container contains both some waste and a ticket describing the state of the waste. Each machine modifies the waste and updates the ticket.  You can also move the ticket into the waste compartment (get) or put some waste in the ticket compartment (put).  Aside: Dell use a ticket called a "traveller" in their build-to-order manufacturing system, which parallels this system closely except for the rule about sealed containers.


 * Paul.


 * Hmm... of course. The notion of 'ticket' could be very easily transfered over to the waste container thing.  Don't know why that didn't occur to me.  Ok, so now what?  Do we start importing text?  Are there other issues to work out? -- Kowey 20:37, 8 January 2006 (UTC)


 * I think we can start importing text. I know I haven't been active recently.  I'm hoping to get back to this soon.  BTW, thanks for getting started with the "Practical Haskell" bit.  -- Paul Johnson 22:31, 10 Jan 2006 (GMT)

From the main page... ''What is almost unique about Haskell is that it is purely functional. If you have a function f on integers, then it really is a function. For exampele f(x) - f(x) will always be zero, you don't need to know the definition of f.'' This statement is at best misleading, and at worst, false. Ignoring for a moment that f(x) will have to be in the class Num (because of the subtraction) in order for your program to compile, it is trivially easy to come up with examples where f(x) - f(x) isn't zero...

main = do       print $ f - f        print $ g - g f :: Double f = 1/0 g :: Integer g = 1 `div` 0


 * I've fixed the f x - f x problem.

Operators
I see we have a bit of minor dispute over how infix functions should be referenced. The articles previously used things like ">>=", and I've been using >>=. I actually prefer (>>=) because that is the way it would be written as a "normal" function. Should I go in and put quotation marks around all those operators, or should we use one of the others? --Ihope127 16:40, 31 December 2005 (UTC)


 * I've been a bit inconsistent myself, mostly as a result of the learning curve on WikiBooks markup. I'm now using &lt;tt&gt; .. &lt;/tt&gt; to flag Haskell keywords and identifiers when used in-line.  I don't want to use brackets around infix operators because it adds visual clutter for newbies, even though it is technically correct.


 * --Paul Johnson 19:05, 2 January 2006 (GMT).

How about quotation marks the first time, and nothing after that? --Ihope127 02:28, 3 January 2006 (UTC)


 * I have no strong views, other than a wish to avoid work and be consistent. If you feel strongly enough to go back and fix everything then I'll be happy to fit in with the convention from now on.  Whatever we do ought to be documented in the notes for contributors though.  --Paul Johnson 23:15, 3 January 2006 (GMT).


 * How about ? That code tag is mighty handy -- Kowey 14:04, 4 February 2006 (UTC)

A CPS draftything
Since talk pages for nonexistent pages never get noticed: Talk:Programming:Haskell_CPS --Ihope127 17:01, 3 February 2006 (UTC)

Metaphor corral
Just a place for just to jot down useful metaphors and mental images for explaining Haskell or functional programming stuff. Of course, not everything needs a metaphor. Somethings are best explained directly...


 * monads - nuclear waste containers
 * monad transformers - monadic sandwiches
 * Parsec - Pacman! (you can use try to make it spit the pills back out)

Renaming
We need to rename the pages, as per Naming policy.


 * It's not entirely clear to me what to rename it to. Can we just name it Haskell? -- Kowey 19:15, 13 June 2006 (UTC)


 * Rename to things like:
 * Haskell (Probably without Programming:)
 * Haskell/Beginning_Haskell
 * Haskell/Beginning_Haskell/Basic_Concepts
 * Haskell/Beginning_Haskell/Lists
 * etc...
 * Haskell/The_Libraries
 * Haskell/The_Libraries/The_Hierarchical_Libraries
 * etc...
 * --Tchakkazulu 22:38, 13 June 2006 (UTC)


 * Works for me, although I would probably just keep the structure pretty flat
 * Haskell/Basic_concepts
 * Haskell/Lists
 * etc...
 * You agree? Anybody else want to comment? -- Kowey 17:25, 14 June 2006 (UTC)
 * You agree? Anybody else want to comment? -- Kowey 17:25, 14 June 2006 (UTC)


 * Starting the move now. Please help, or complain if you disagree -- Kowey 06:11, 16 June 2006 (UTC)

Write yourself a Scheme in 48 hours
Johnathan Tang has given just permission to import Write yourself a Scheme in 48 hours into the wikibook! There's great material for Parsec and practical Haskell that we could mine from this book. Many thanks, Johnathan. -- Kowey 17:24, 14 June 2006 (UTC)


 * Note that this import is now complete, and can be found at Haskell/Write Yourself a Scheme in 48 Hours - now all the remains is to mine it for content in the main wikibook -- Kowey 00:33, 9 July 2006 (UTC)

Use of the term 'statement'
The only appropriate place to use the term 'statement' is in the context of the lines of a do-block (but not for the do-block as a whole, or in reference to let or if). It's used in error in a bunch of places here, try to correct any incorrect uses you see.


 * Thanks for pointing this out. Would the appropriate fix be s/statement/expression/ where relevant? -- Kowey 09:20, 21 June 2006 (UTC)

PLEAC code considered harmful
I've removed the link to PLEAC, because the code there isn't educational. The code is barely recognizable as Haskell. For example, the author overrides the (.) operator (usually used for function composition) to an OO like application operator. (^) is changed from exponentation to concatenation. These are just a few of the problems at PLEAC; we really can't recommend this material to those learning Haskell.