favorite Haskell tutorial 
Author Message
 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 two-function 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  
 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 haskell-98-tutorial 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  
 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  
 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
type-classes. 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)" (Java-like)
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 two-function 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 anti-virus system ( http://www.*-*-*.com/ ).
Version: 6.0.495 / Virus Database: 294 - Release Date: 30/6/2003


Fri, 23 Dec 2005 02:28:15 GMT  
 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  
 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 three-parameter 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 multi-parameter 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 ad-hoc 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 top-level 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  
 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 three-parameter 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  
 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  
 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 three-parameter 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 ad-hoc 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  
 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  
 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  
 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/2003-January/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  
 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  
 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 semi-formal 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 run-time, 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  
 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  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. haskell tutorial, information

2. haskell, german tutorial

3. Haskell 98-- Tutorial?

4. Haskell tutorial

5. Haskell Report version 1.2 and tutorial now available

6. Haskell, Miranda to Haskell

7. ANNOUNCE: Glasgow Haskell 2.01 release (for Haskell 1.3) [repost]

8. ANNOUNCE: Glasgow Haskell 0.29 release (for Haskell 1.2) [repost]

9. ANNOUNCE: Glasgow Haskell 0.29 release (for Haskell 1.2)

10. Smalltalk Books/Tutorial - Tutorial for GNU

11. awk Tutorial: Fees Reduced and Tutorial Descriptions for

12. Java Tutorial: Fees Reduced and Tutorial Descriptions for

 

 
Powered by phpBB® Forum Software