Lambda the Ultimate

- In the the fifth and sixth couplets, the function twice was omitted by mistake.

- (map (o twice son-of-twice) '(1 2 3)) should be (map (o son-of-twice son-of-twice) '(1 2 3))

- I noticed that my protagonists are a bit more neurotic than ussual. That's what trying to be pure does to a man.

Well, the rest would probably be in Haskell. This introductory chapter gives the motivation for a pure, typed language, with automatic currying.

There are some stylistic points as well, IMHO, but it whet my appetite for the rest of the book, so I'd say it's a success!

I enjoyed this chapter Ehud, but I think to you need a more compelling example than the use of set! to motivate the switch to Haskell. (After all, you could just avoid using set! and use a pure style)

You allude a bit to the kinds of problems that can arise from the lack of attention to typing, but I'm sure there is a more hair-raising example of this you could use. (I'm sure I could find one in my old Scheme code ;-) )

Another alternative would be to use a more necessary use of set!, such as the standard representation of letrec. This give a nice motivation for laziness too.

I actually like the neurotic edge; provides a nice satirical homage to the original which adds to the enjoyment. ;-)

On the whole, I nice start. I'd certainly add it to my collection (especially since I've been spending some time on Haskell lately).

Matt: the initial definition of son-of-twice contains a typo

Noticed that, thanks. This is a just something I wrote this morning before breakfast. I guess it shows

Marc: you need a more compelling example than the use of set! to motivate the switch to Haskell

The point wasn't to motivate switching tio Haskell, but rather to show how equational reasoning can fail. The conclusion should have emphasized this ("since we want to able to algebraically manipulate code, we want strict control over side effects").

The same goes for typing. It's not that I wanted to motivate strong typing. The typing issues arise naturally, since I try to partially apply a function and get an error message. Typing isn't really important in this dialogue, and maybe it really is just a red herring.

I quite fancy The Little Manipulator as an alternative title - it would go well with The Little Schemer...

I'd certainly be interested to read the rest of this, if there is (or is going to be) a rest.

"since we want to be able to algebraically manipulate code..."

(Passing VB-yokel): Why?

One thing I'd hope for from a book like this would be to gain some sense of what equational reasoning about programs is good for. So it would be nice to work over a few chapters towards some result that wasn't either trivial or "just obvious" on the basis of what the VB-yokel (myself, in this instance) might be pleased to think of as his "intuition". Perhaps two contrasting examples would do it: one in which we uncovered a non-obvious flaw in a highly plausible-looking implementation of some algorithm, and another in which we proved a result that helped us to improve the implementation of some other algorithm (or that maybe enabled us to automate the transformation of some code to use CPS, or something like that - the more it looks like magic, the better).

That sounds more like a novel by Nabokov than a programming language textbook. :)

That sounds more like a novel by Nabokov than a programming language textbook. :)

LOL. Best LtU one liners ever!

Examples of low level optimization (map (-1) (+1) x == id), higher level optimization (see the recent post about maximum segment sum for a nice example), proving correctness (as well as how reasoning can break in the presence of side effects, like in the example in the file I posted) and maybe even a more detailed example of deriving from specifications.