Why all the lambdas in The Little Schemer?

Question

After learning a bit of Scheme from SICP, I started reading The Little Schemer (which I find quite entertaining) and am about one fourth done. I noticed that I can write many (most? all?) solutions without using lambda whereas The Little Schemer always uses them. For example, the very first definition is

(define atom?
  (lambda (x)
    (and (not (pair? x)) (not (null? x)))))

which, unless I am mistaken, can be written more simply as

(define (atom? x) 
   (and (not (pair? x)) (not (null? x))))

Am I missing something fundamental if I write lambda-less solutions?

Answer 1

Originally, define had a single syntax, to set a variable to a value. That's the style used in such old (and timeless) books. Later on, define got a different syntax as a shortcut, which is the one you're using.

Just for fun, search on your Scheme libraries, you might find a macro that expands the non-lambda form into the old lambda-heavy one.

Answer 2

I vaguely remember a professor discussing something like this.

I think the lambda solution is used for two reasons:

The first is purely a historical thing. At one point in time, that was the only way it was possible. So some people still use that method.

The second is that some people just like to be more explicit about the fact that a function is being created, so they like to see the word lambda.

So I believe the choice comes down to what ever you personally like the best.

Answer 3

The Little Schemer uses a pseudo-code Scheme (to make simplifications for educational purposes and to be implementation-independent). Today's standard Scheme has a definition of define in which you are implicitly invoking lambda (see http://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_7.html). The Little Schemer scheme is very simple and does not include this alternate form.

Answer 4

I strongly prefer the lambda-heavy style for teaching, since it makes function creation more explicit, as Jay says.

When learning, the simple functions you start with like atom? are defined at the top level. This means it's possible, and even more compact, to create the function with the defun-style define you mention.

However, when you start using functions as first-class values, e.g., as an argument to map, you'll be seeing lambda for the first time, and it might seem weirder and more magical than it really is.

Instead, if you've been defining your functions with lambda the whole time, it's less of a leap to see that functions are just like any other value. They happen to be on the right-hand side of define pretty frequently, but are no different from a number or a quoted constant:

(define x 1)
(define l '(2 3 4 5))
(define s (cons x ls))
(define f (lambda (n) (+ n 2)))

Of course, the language supports both forms, so it comes down to style eventually. To me, there is an appealing consistency in the usage of define when all of your functions are made with lambda: the first argument is always a symbol, and the second argument is just any old expression. And the fact that lambda is just like any old expression is one of the most important things for any functional programmer to learn.

Answer 5

You can see what your Scheme expands these shortcuts (macros) into using expand (if supported):

mzscheme 4.2.4 (with DrScheme):

> (expand '(define (add1 x) (+ 1 x)))
#<syntax (define-values (add1) (lambda...>
(define-values
  (add1)
  (lambda (x) (apply + '1 x)))

Chez Scheme 8.0:

> (expand '(define (add1 x) (+ 1 x)))
(begin
  (set! add1
    (lambda (x)
      (+ 1 x)))
  (void))

The lambda appears plain as day.

Answer 6

I'm reading a bit about lambda calculus (reading "The Implementation of Functional Programming Languages" by Simon Peyton Jones; free pdf on-line) as I use TLS. And so this is just a guess, but I believe the authors of TLS want you to really be lambda-heavy in your thinking. They don't come out and say it, but there are hints (check out p. 107 of TLS) that this is all just an exercise in applied lambda calc. So maybe they're saying without saying, "You're doing lambda abstractions, my friend!"