favorite Haskell tutorial
Author 
Message 
Marshall Spigh #1 / 22

favorite Haskell tutorial
Hi all, I'm a regular joe working programmer (years of C++; lately years of Java) and I want to expand my horizons. I've been dipping my toe in lots of different languages, and I find myself very attracted to Haskell. So now I'm trying to figure out how to learn it. I figured a decent tutorial would be pretty easy to find, but apparently I was wrong. The tutorials I've come across so far have been unsatisfactory. They present the information in weird ways and in an odd order. No, I don't think this is just the difference between imperative and functional code; one tutorial I had asked the reader to write a function of two arguments when it had only presented the syntax for functions of one argument! Some pages later it described the twofunction argument syntax. I'm not thrilled to be poking around in Hugs and having 98% of what I type return some kind of error. If it were only 75% that would be okay. :) Anyone have any recommendations for learning Haskell? Good books? Good tutorials? I've poked Google pretty hard and even tried searching for "favorite haskell tutorial" on this group, but I'm not getting what I want. Your help appreciated. Marshall

Fri, 23 Dec 2005 00:14:17 GMT 


Frank Bus #2 / 22

favorite Haskell tutorial
Quote:
> Anyone have any recommendations for learning Haskell? Good > books? Good tutorials?
I'm learning Haskell, too, but I didn't found the one tutorial which fits it all. But a good starting point is this tutorial: http://www.***.com/ (the font looks ugly on my computer, so I've recompiled the{*filter*}source: http://www.***.com/ , perhaps someone can update the PDF on the haskell site with my PDF) For things you don't find in the haskell98tutorial you can search in this tutorial: http://www.***.com/ ~cs208/subpages/Tutorials/HugsT/hugs.pdf together with this reference (you can download it for offline browsing): http://www.***.com/ and with the Haskell 98 report: http://www.***.com/ you have a good collection for learning and programming in Haskell. 
http://www.***.com/ , http://www.***.com/

Fri, 23 Dec 2005 01:12:04 GMT 


Peter Simon #3 / 22

favorite Haskell tutorial
Quote: Marshall Spight writes:
> Anyone have any recommendations for learning Haskell? You'll find a list of resources at: http://haskell.org/learning.html I can recommend the book "Haskell: The Craft of Functional Programming", which I used to learn Haskell. It's listed on the page above as well. Peter

Fri, 23 Dec 2005 01:25:58 GMT 


Daniel Yokomis #4 / 22

favorite Haskell tutorial
Hi, From the haskell site you'll find the http://www.***.com/ #tutorials section. There are lots of tutorials (at least more than 10 :) available. My preferred is "A Gentle Introduction to Haskell" http://www.***.com/ ; which is a bit technical but, if you have no problem with functional programming, pretty enlightening. But functional programming paradigm is very far from imperative programming, specially Haskell, with currying, lazyness and typeclasses. I know how hard it can be for imperative guys (I'm a professional Java developer :( ). I'll comment on one of your statements: Quote: > No, I don't think this is just the difference between imperative > and functional code; one tutorial I had asked the reader to write > a function of two arguments when it had only presented the > syntax for functions of one argument!
An important remark must be made. In Haskell juxtaposition is function application, you don't need special characters, so "f(a, b, c)" (Javalike) would be "f a b c". Also it reads left to right, so it's equivalent to "(f a) b c" or "((f a) b c)". That means two important things: every function can be curried, and you can't distinguish a function with two parameters from a function that takes one parameter and return a function that takes one parameter and gives the answer. This feature is a far step from imperative languages and is related (partially) to equational reasoning. When you understand currying, combinators seem a very pleasant way to work. Best regards, Daniel Yokomiso. "{*filter*} & calculus don't mix. Never drink and derive."
Quote: > Hi all, > I'm a regular joe working programmer (years of C++; lately years of > Java) and I want to expand my horizons. I've been dipping my toe > in lots of different languages, and I find myself very attracted to > Haskell. > So now I'm trying to figure out how to learn it. I figured a decent > tutorial would be pretty easy to find, but apparently I was wrong. > The tutorials I've come across so far have been unsatisfactory. > They present the information in weird ways and in an odd order. > No, I don't think this is just the difference between imperative > and functional code; one tutorial I had asked the reader to write > a function of two arguments when it had only presented the > syntax for functions of one argument! Some pages later it > described the twofunction argument syntax. > I'm not thrilled to be poking around in Hugs and having 98% of > what I type return some kind of error. If it were only 75% that > would be okay. :) > Anyone have any recommendations for learning Haskell? Good > books? Good tutorials? I've poked Google pretty hard and even > tried searching for "favorite haskell tutorial" on this group, but > I'm not getting what I want. > Your help appreciated. > Marshall
 Outgoing mail is certified Virus Free. Checked by AVG antivirus system ( http://www.***.com/ ). Version: 6.0.495 / Virus Database: 294  Release Date: 30/6/2003

Fri, 23 Dec 2005 02:28:15 GMT 


Marco Lang #5 / 22

favorite Haskell tutorial
Hi! Quote: > I can recommend the book "Haskell: The Craft of Functional > Programming", which I used to learn Haskell. It's listed on the page > above as well.
This is absolutely true. Although I do not possess this book (yet), I read it (not complete, but many parts) in the university library, and it is IMHO an excellent book. Best regards, Marco

Fri, 23 Dec 2005 02:24:49 GMT 


Joachim Durchhol #6 / 22

favorite Haskell tutorial
Quote:
> That means two important things: every function > can be curried, and you can't distinguish a function with two parameters > from a function that takes one parameter and return a function that takes > one parameter and gives the answer.
What Daniel alludes to is this: If f is a function of three parameters A, B, and C, and you write f x then this will return you a new function of parameters B and C, with "x" substituted in wherever there was "A" in the original function body. Actually, if you declare a threeparameter function in Haskell, the syntax doesn't tell you that you're actually defining a function that takes a parameter and returns (a function that takes a parameter and returns (a function that takes a parameter)). Actually this isn't particularly functional. There are functional languages that have normal multiparameter functions. And imperative languages could work that way as well. It's just that this type of reasoning makes some things conceptually simpler in a functional context. A similar reason goes for not having parentheses around parameters. I.e. you don't write "sin (x)" as in C or Java, you write "sin x" as in mathematics. If you want to take the sine of "x + y", you'll still have to write "sin (x + y)", but these parentheses are there to make sure that you don't mean "(sin x) + y". In combination, these two properties of Haskell can make for amazingly compact yet readable code. For example: foldl fun start list takes a "start" value, accumulating the "list" elements using "fun" ("fun" must take a value of the same type as "start" and a list element, and return a value of the same type as the "start" value). (The name is due to historic reasons that don't interest right now.) foldl (+) is a function that takes two parameters, a start value and a list, and adds all the values of the list to the start value. foldl (+) 0 is a function that, when called with a list, returns the sum of the list elements. If Haskell had multiple parameters and argument parentheses, the latter function would look like listsum (l) = foldl ((+), 0, l) and you'd not be able to write it down in an adhoc manner, you'd have to invent a name for it. This "just a single parameter" business (called "currying" as Daniel wrote) makes for a very "sticking functions together" style. For example, the return value of a function might be a record of functions. With currying, you can write a function that manipulates these function records, selecting, concatenating or otherwise manipulating these functions into a new whole, without ever executing a single line of all these functions  and the toplevel of the program looks like this: f = some_humongous_function_that_constructs_a_function f arguments In other words, you first construct a function that "does the right thing given the circumstances", then you set that function loose on the arguments that happen to be submitted to the program. (I'm not a Haskeller, so access to the command line is probably not done via an "arguments" function but differently, but I hope it's clear what I mean *g*). Hope this clarifies things a bit further. Jo

Fri, 23 Dec 2005 06:20:57 GMT 


Marshall Spigh #7 / 22

favorite Haskell tutorial
Quote:
> If f is a function of three parameters A, B, and C, and you write > f x > then this will return you a new function of parameters B and C, with "x" > substituted in wherever there was "A" in the original function body. > Actually, if you declare a threeparameter function in Haskell, the > syntax doesn't tell you that you're actually defining a function that > takes a parameter and returns (a function that takes a parameter and > returns (a function that takes a parameter)).
Am I correct in assuming (from the syntax) that this only works if I want to supply (A, B, C), or supply (A, B), or supply (A)? What if I only want to supply (B,C)? I can't see a basis for selecting an ordering for my function parameters such that I'm confident I got it right. Marshall

Fri, 23 Dec 2005 11:54:47 GMT 


gr.. #8 / 22

favorite Haskell tutorial
:> If f is a function of three parameters A, B, and C, and you write :> f x :> then this will return you a new function of parameters B and C, with "x" :> substituted in wherever there was "A" in the original function body. : Am I correct in assuming (from the syntax) that this only works if I : want to supply (A, B, C), or supply (A, B), or supply (A)? : What if I only want to supply (B,C)? You could write: g a = f a b c to create a function g, then use that function elswhere, but you can't just use (f b c) as an anonymous expression the way you can with (f x). There is, however, a Prelude function "flip" defined as: flip f x y = f y x which allows you to use (flip x y) as an anonymous expression. You could write a version that works similarly for three arguments, but for the general case you would need to use "records". Greg

Fri, 23 Dec 2005 12:25:03 GMT 


Mark Alexander Wott #9 / 22

favorite Haskell tutorial
On Mon, 07 Jul 2003 03:54:47 GMT, Marshall Spight posted: Quote:
>> If f is a function of three parameters A, B, and C, and you write >> f x >> then this will return you a new function of parameters B and C, with "x" >> substituted in wherever there was "A" in the original function body. >> Actually, if you declare a threeparameter function in Haskell, the >> syntax doesn't tell you that you're actually defining a function that >> takes a parameter and returns (a function that takes a parameter and >> returns (a function that takes a parameter)). > Am I correct in assuming (from the syntax) that this only works if I > want to supply (A, B, C), or supply (A, B), or supply (A)?
Yes, that's right. Quote: > What if I only want to supply (B,C)? I can't see a basis for > selecting an ordering for my function parameters such that > I'm confident I got it right.
There are a few ways around this. In practice, I tend to refactor my programs when it becomes obvious that a particular ordering is more useful, but there are less adhoc methods. Ocaml can use named fields, I think: another possibility is using wrapper functions like "flip": Prelude> :t flip forall c a b. (a > b > c) > b > a > c Or you can write your own, of course. mrak  realise your life was only bait for a bigger fish  aesop rock

Fri, 23 Dec 2005 13:32:22 GMT 


Adrian He #10 / 22

favorite Haskell tutorial
Quote:
> :> If f is a function of three parameters A, B, and C, and you write > :> f x > :> then this will return you a new function of parameters B and C, with > :> "x" substituted in wherever there was "A" in the original function > :> body. > : Am I correct in assuming (from the syntax) that this only works if I > : want to supply (A, B, C), or supply (A, B), or supply (A)? > : What if I only want to supply (B,C)? > You could write: > g a = f a b c
or you can just use an anonymous lambda abstraction if you don't want to name the new function.. (\a > f a b c) Regards  Adrian Hey

Fri, 23 Dec 2005 15:55:33 GMT 


Adrian He #11 / 22

favorite Haskell tutorial
Quote:
> What if I only want to supply (B,C)? I can't see a basis for > selecting an ordering for my function parameters such that > I'm confident I got it right.
One useful rule for higher order funtions (e.g. map, foldr etc) is to include function arguments first, as these are commonly specialised in expressions like this (map (+1)), (foldr (++)).. if map was defined.. map [] _ = [] map (x:xs) f = f x : map xs f you'd end up writing expressions like this a lot.. (\xs > map xs f) instead of just.. (map f) Regards  Adrian Hey

Fri, 23 Dec 2005 16:10:23 GMT 


Ketil Mald #12 / 22

favorite Haskell tutorial
Quote:
> Anyone have any recommendations for learning Haskell? Good > books? Good tutorials?
I haven't looked at it myself, but from the announcements, Helium seems like a good tool to start with. http://www.haskell.org/pipermail/haskell/2003January/011071.html Keeps you out of the more complex and esoteric entanglements, and gives understandable error messages. Sounds like a good idea to me. kzm  If I haven't seen further, it is by standing in the footprints of giants

Fri, 23 Dec 2005 17:54:43 GMT 


David Basil Wildgoo #13 / 22

favorite Haskell tutorial
A good book may be useful. I recommend "Algorithms  A Functional Programming Approach" by Fethi A. Rabhi and Guy Lapalme as an excellent introduction to Haskell. As you can guess from the title, it is actually about functional programming using Haskell, but it begins with a concise, extremely clear and very readable introduction to Haskell that is better than any I have seen anywhere else. (Especially to someone like me who is approaching Haskell from an imperative background). It then uses that knowledge to illustrate the creation of efficient Haskell programs. Its main failing is that it doesn't do much more than mention "Monads" at the end of the book, but this is largely true of "Haskell: The Craft of Functional Programming" as well. I have yet to see a proper, clear treatment of Monads. Perhaps Hudak's book (mentioned in a posting above) takes the right approach by just using them without explaining them.

Fri, 23 Dec 2005 18:05:40 GMT 


Joachim Durchhol #14 / 22

favorite Haskell tutorial
Quote:
> Its main failing is that it doesn't do much more than mention "Monads" > at the end of the book, but this is largely true of "Haskell: The > Craft of Functional Programming" as well. I have yet to see a proper, > clear treatment of Monads. Perhaps Hudak's book (mentioned in a > posting above) takes the right approach by just using them without > explaining them.
I don't think that "just using them" is a good approach. This will just foster misconceptions, which lead to misuse, which leads to dissatisfaction because the misuse doesn't work well. I have been thinking about Monads and the semiformal definition near the end of Hudak's "Haskell School of Expression", and this is what I arrived at (hopefully somebody can correct the obvious errors that I most likely have in it):  snip  Monads are just functions stuck together as a sequence. The point is that one can do this sticking together at runtime, selecting functions according to, say, user input. Note that the functions are not evaluated; to evaluate the whole thing, the program must supply an argument with which to call the monad. The monad will submit the parameter to the rightmost function in the list, take the result, possibly transform it in some way, then feed the value to the next function, and so on. Finally, it will return the result of the last function (again, after potentially transforming it). This is an extremely powerful technique that's used for a variety of purposes. For example, the Maybe monad handles sequential computations that may fail at any point. Functions for the Maybe monad may return one of two types: either Just X (where X is the normal type of the function), or Nothing. The monad will abort the computation as soon at one of its internal functions and return Nothing; otherwise, it will return Maybe Y, the result of the last function evaluated. A close relative of Maybe is Exception. Instead of Nothing, it will expect (and return) Exception Something, where Something is some exception information. State is a simulation of imperative programming. Each inner function must take a state parameter and return a new state value and a result. The monad is constructed with an initial state. The entire monad, when evaluated, will apply the rightmost function to the initial state value and the parameter, handing over the intermediate states and results to each function in turn, finally discard the state and return the result.  snip  Regards, Jo

Fri, 23 Dec 2005 19:28:50 GMT 


Stefan Axelsso #15 / 22

favorite Haskell tutorial
Quote:
> Its main failing is that it doesn't do much more than mention "Monads" > at the end of the book,
On the subject of Monads and tutorials I've found Noel Winstanley's "What the hell are Monads?" the most helpful. (http://www.abercrombiegroup.co.uk/~noel/research/monads.html). It's not a complete textbook though, far from it, it's a faily short introduction, so it's more in reply to the original poster than your request. Regards,  Stefan Axelsson (email at http://www.cs.chalmers.se/staff/sax)

Fri, 23 Dec 2005 21:25:19 GMT 


Page 1 of 2

[ 22 post ] 

Go to page:
[1]
[2] 
