Saturday, June 23, 2012

Land of Lisp chapter 6.5 - Lambda

Okay, the chapter (sort of) on lambda. Perhaps I'm dense, or inexperienced, or just plain stupid but I'm not sure I see what all the hype is. This (half) chapter, for all its hyperbole, does little to dispel the mist surrounding the importance of the lambda.

It begins with a discussion about how functions are first class values in Lisp. You can pass them around the same way you do any other variable (presumably you can edit them as well... (cdr #'myfunc) being the list of parameters perhaps? But now I'm talking about things I don't know...). This is well and good and useful. You can pass them on to higher order functions all over the place if need be.

To come back to lambda, the special form is

lambda is a macro, not a function, and returns an anonymous function (not a macro, or a llama). Because lambda is a macro it doesn't evaluate all of its parameters prior to execution, so the {code} passes in unaltered (I assume anyway) by the parser.

I suppose what I'm failing to understand is how this is more useful than, say, constructing an actual function (if you need it more than once) or simply placing code inline. For example:

Is functionally equivalent to

and

(I suppose both of those are really the same solution, one just explicitly recurses where the other lets mapcar deal with that complexity) Once I've defuned a function I can use it in multiple places. A lambda function is, by virtue of its anonymity, incapable of such feats (unless, again, I'm missing something?).

Now that I try to think about it though, there doesn't seem to be a C-like loop structure in Lisp. Not that I've gotten to yet anyway. If there is you should be able to simply put the (/ x 2) inside the loop directly. (Edit: There is, it's in the next chapter!)

Now, is the lambda code above 'cleaner'? That depends. A neophyte would probably say 'no'. The mapcar snippet is nearly as concise and more human readable (which is desirable) to a beginner. A programmer steeped in Lisp will, apparently, disagree.

Then of course there's the near-mysticism that the author gets into about Lisp growing out of lambda calculus and how it's really sort of the only function in Lisp, etc. Which is great if you live in an ivory tower and get a stipend for getting other people's brains in knots (especially if you still appear to know what you're talking about). Unfortunately, I don't see (yet?) how this makes Lisp superior to other languages. But. This is the first brush with it and clearly there's something here if the amount of ink spilled on it is any indication. So hopefully understanding will come shortly.

No comments: