Finding a good functional programming Tutorial

[Jerem000]

Hi everybody, it's been a long time !!! I hope you guys have had lot of fun since I have seen you !!!

I've got a question for Vincent : where can I find good tutorials on functional programming ? I am currently trying to learn Erlang programming and it appears to be hard to find good courses (at least good free courses). So I was wondering if there may be some good stuff on the internet about similar others languages and if you know were I could find it.

Well I hope to see you soon guys and until then have fun !!!

[Vincent]

Hi there!

I've got a question for Vincent : where can I find good tutorials on functional programming ? I am currently trying to learn Erlang programming and it appears to be hard to find good courses (at least good free courses). So I was wondering if there may be some good stuff on the internet about similar others languages and if you know were I could find it.

Well, I have a fair number of sources on OCaml and -- to a lesser extent -- Haskell, but I think learning them in order to learn Erlang might be overkill.

On functional programming in general, I recommend the famous MIT 6.001 course material, which uses Scheme. The nice thing about Scheme -- and LISP dialects in general -- is that they have virtually no syntax, which lowers the learning curve a bit and makes it a tad easier to focus on the underlying ideas. In the same line of thought, it might be a good idea to learn the basis of -calculus; don't spend too much time on it though; if you "get it" it will certainly help you, if not it's not the end of the world.

As for Erlang, specifically, I have never used it, but the "getting started" on the official website seems quite complete: http://www.erlang.org/starting.html .

General advice:

1) In FP, lists and higher-order functions are absolutely fundamental; once you have the basics for your language's syntax, spend as much time as necessary playing with them. Using a "map" should become every bit as natural to you as writing a "for" loop. A good way of achieving that it to re-implement your language's standard library on lists from each function's specification. For instance this for OCaml.

2) "Practice makes perfect"

Well I hope to see you soon guys

Are you still on Besançon ?

[Jerem000]

Thanks Vincent for the quick answer, as you can see, I am as quick as you to reply.

I am gonna watch carefully the SICP courses, my Scheme skills being a little rusty (understand by that almost dead) it's a good idea to start there. Since I am not able to program a flatten function in Scheme anymore it wont hurt.

To be honest I don't think I am gonna crack the mysteries of lambda calculus even if I understand what currying is about. Well, more precisely, I understand what it currying does, but not what it is useful for or what it really brings to the table. I have only seen that Haskell type system curry functions to express the type of a function with multiple parameters. (tell me I am not mistaking here)
By the way, Haskell seems to be nice, even if the type system make you cry and scream as long as you're not use to it. (I won't talk about monads, I am too far from being able to understand the very beginning of the concept :-) )

I think I understand higher order functions like the unavoidable map function for instance. Take a function as parameter to apply it to a data structure, the idea isn't that complicated, and I think with practice i'll find good uses for it. One of the concept I worked a lot with in my early days in scheme (PFA with M. Hufflen) was closure. Call me dumb but, yet, I don't see the purpose of that feature. I hope the MIT course will help me about that.

Well I won't talk anymore, I think I have made enough mistakes in my english and in the concepts that I describe. Thanks again for the MIT course which seems to be the best possible start, cause the Erlang website describes the language, what the language is for (coding servers distributed systems in general, which wasn't your cup tea if I remember), not the FP philosophy.

I might find myself in Besançon this week, I'll try to pass by and say hi.

Have Fun.

[Vincent]

I have only seen that Haskell type system curry functions to express the type of a function with multiple parameters. (tell me I am not mistaking here)

Correct. Every language I know of in the ML family does that -- Standard ML, OCaml, Miranda, Haskell etc... It comes straight from -calculus, where is just syntactic sugar for

Trivial Caml example: if add x y = x+y then List.map (add 1) l just adds one to every element of the list l, because "add 1" is a function of type .

I'm not sure, but I don't think Erlang does currying. Neither does Scheme -- though you can write curried functions explicitly, of course. So don't lose sleep over it.

By the way, Haskell seems to be nice, even if the type system make you cry and scream as long as you're not use to it. (I won't talk about monads, I am too far from being able to understand the very beginning of the concept :-) )

Haskell is not just "nice". It's absolutely awesome! As much as I love OCaml, I find Haskell to be more consistent, and less "rough around the edges". As for Monads, they are extremely hot stuff; not only can you handle stateful computations in a purely functional way, but you can for instance chain computations which may fail with the Maybe monad, or write (pseudo) non-deterministic algorithms with the List monad etc. The learning curve of Haskell is quite steep though; if I did not have a few years of experience with Caml, I think I would be quite lost...

Just one thing: Unless I'm sorely mistaken, Erlang is dynamically typed; Caml and Haskell are very strongly typed; learning them may in the end make you a better programmer in any language, but it is not of direct interest for learning Erlang -- and Haskell may fry a few of your neurons OTOH Scheme is dynamically typed, so closer to Erlang in that respect.

Call me dumb but, yet, I don't see the purpose of that feature.

I think SICP has a section on that early on -- first chapter or so. It's so natural a feature that you really don't need to think about it most of the time; it simply says that if you write a function (say "f") that uses a certain value "x" in its definition, and pass it around your program, "f" will always use the value "x" had when it was defined, and not whatever value might be called "x" in the context where it is used -- for "f", those are two different "x"s.

I might find myself in Besançon this week, I'll try to pass by and say hi.

Please do so. But note that neither I nor Mathias are in our offices 24/7, dropping us a mail in advance might help us synchronise

Have Fun.

Always.

[Jerem000]

Hi vincent,

I am going through the SCIP book and thank you for the reference. The book is pretty awesome even if it is pretty hardcore !!! (I still don't get the solution the give for the "eight queens puzzle")

I don't know if you have already read the article http://www.joelonsoftware.com/articles/ ... hools.html, but if JMH had told us what is explicitly said in this, I wouldn't have forgotten lots of stuff I did in master 1 PFA course. So here I am trying to build abstractions, playing with higher order functions, ...

Anyways the reference is pretty good even if I am not so much interested in Erlang anymore. To be honest I read a lot of articles about Haskell, watched the presentation video of Haskell by Simon Peyton Jones at OSCON 2007, and had been through much more other resources on the web.
I can see it now !!! I can see what is so fuckingly mind blowing with this language !!! Well at least I am starting to be able to see what is fuckingly mind... I still don't have my mind ready to think in a monadic way but when I'll be done with the first three chapters of SCIP I'll invest a lot of time in Haskell even if it could fry some of my neurons.

It is a long post too say thank you for the SCIP book but I had too share my brand new excitement for Haskell with somebody that won't think I am a creep saying things like that.

See you.

[Vincent]

I don't know if you have already read the article http://www.joelonsoftware.com/articles/ ... hools.html,

Yes, I have. This is one instance where I mostly agree with what Joel says.

Other articles by him which I find interesting are
http://www.joelonsoftware.com/articles/ ... 00319.html
http://www.joelonsoftware.com/articles/ ... tions.html
(and this is especially interesting when read with Haskell in mind, because Haskell has some very powerful abstractions, which can leak very hard for reasons which are quite obscure until you learn what exactly is going on under the hood...)

It is a long post too say thank you for the SCIP book but I had too share my brand new excitement for Haskell with somebody that won't think I am a creep saying things like that.

You are welcome.

And welcome to the Dark Functional side of the Force

[Jerem000]

Hi,

The articles you advised me are really good too ! Especially the one about abstraction leaks. I would be interested to see some of those in Haskell if you have some examples.

I might learn how to program in OCaml too (I know, I know, I want to do a lot of things). I found this website : http://functionaljobs.com/ in which there is an ad for job at Jane Street http://www.janestreet.com/. This company fully work in OCaml and seems to be a very good place to work in. I am gonna apply for a job there, well it doesn't mean they will hire me but I'd like too. If you had told me in second year, when I was programming a bit with OCaml and A. Giorge..., that I might seek for an OCaml job someday, I would have laugh at your face. And now, here I am.

Anyway thank for the help and if you have some abstraction leaks in Haskell to share I am interested.

Later.

[Vincent]

If you had told me in second year, when I was programming a bit with OCaml and A. Giorge..., that I might seek for an OCaml job someday, I would have laugh at your face.

It's never a good idea to laugh at my face

Anyway thank for the help and if you have some abstraction leaks in Haskell to share I am interested.

I had interesting, specific examples at some point, but I have forgotten them

On the top of my head:

Take foldl, for instance; in a strict language, such as OCaml, it does not build a stack, while foldr does. So the latter can result in a stack overflow, while the other cannot. (Note: in Caml those functions are called fold_{left,right}, in the List module).
But in a lazy language, such as Haskell, foldl delays the computation into thunks, which can be extremely costly in both space and time and, in extreme cases, results in either saturating Gigabytes of memory, or throwing a stack overflow, depending on implementation.
So a Haskell programmer has do do some "strictness analysis" in her head to determine whether laziness is an asset or a liability.
If it's an asset, use foldl, if it's a liability, use foldl', which is a strict version of foldl. (the compiler does that too, but it's still a (smart-ish) dumb machine...)

More generally, laziness is a very leaky abstraction; it works wonders in some cases, and causes equally impressive havoc in others. If you skim through Haskell's libraries' code, you'll see plenty of cryptic annotations, all geared towards bringing back some strictness where necessary. Without that things would be slow as hell.

I'm sure there are more impressive examples out there; I'll find them when I get more time -- right now I'm writing a paper and the deadline is looming close... and it has nothing to do with Haskell.

I might learn how to program in OCaml too

Then start with OCaml, it's easier and more "reliable", in the sense that it requires far less voodoo to get efficient programs in Caml than in Haskell. Caml progs pretty much "just work". Unless you're lucky Haskell progs can (and will) be very slow until you figure out where the abstraction leaks, precisely.
So Caml's a very good stepping stone for Haskell. (Haskell Caml++++, albeit with a few minuses as well, nothing's perfect).


Okayyy, that post came out bigger than I intended. Back to work with me.

Cya.

[Jerem000]

Hi Vincent,

Since we spoken yesterday I re-started hacking GHC code a bit. Taking a bit about monads always make me want to understand them and I found something like this in the State monad implementation:

Code: Select all

(# new_s, r #)

My problem here is that I either don't understand nor can't figure about what the '#' are doing here. Hope you got an idea because google isn't my friend when I ask him things like "haskell character #"...

I hope it's not a stupid question !!!

Take care.

[Vincent]

Hi,

It's not a stupid question (at least I don't think it is). I have no idea what this is.

Could you provide a link to the exact source file where you found that?

[Jerem000]

I got it when I extracted ghc sources from the tarball at the location:

whatever/ghc-7.0.1/libraries/base/GHC/ST.lhs


the complete code is this

Code: Select all

instance Monad (ST s) where
    {-# INLINE return #-}
    {-# INLINE (>>)   #-}
    {-# INLINE (>>=)  #-}
    return x = ST (\ s -> (# s, x #))
    m >> k   = m >>= \ _ -> k

    (ST m) >>= k
      = ST (\ s ->
        case (m s) of { (# new_s, r #) ->
        case (k r) of { ST k2 ->
        (k2 new_s) }})

May be it's ghc specific for documentation generation purposes or anything else, I don't know. Inside the comments in the file they talk about using strict evaluation in the State monad but I thought that you specify strictness with the ' ! ' character... thus I'm lost

[Vincent]

Ok, I know.

Those are simply unboxed tuples. Semantically, you can replace them by ordinary tuples; they will act the same. Of course, unboxed is more efficient, but restricted in how you can use it.