What's the reason for using lambda expressions to define functions in Scheme?

Question

I am reading the The Little Schemer book by Daniel Friedman. I don't understand why every function in the book is written with a lambda expression.

(define fun1
  (lambda (x1 x2)
    (+ x1 x2)))

(define (fun2 x1 x2)
  (+ x2 x2))

The two functions do the same thing, but the second one is neater. I am curious about the reasons to use lambda everywhere.

I used DrRacket in this case.

Villalba

Answer 1

(define (x . a) ...) 

is just an abbreviation for

(define x (lambda a ...))

In the very first scheme report from 1975 you didn't have this abbreviation. In the revised report from 1978 it was introduced.

The little Schemer is just a later edition of The little Lisper from 1974. It predates Scheme and when fixed to follow Scheme they tried to keep is as close to the original as possible. Besides when you use (define x (lambda (arg1) ...)) it's obvious that procedure bindings are not different from other variable bindings other than the object it points to is closure code rather than data.

If you look at the SICP video lectures you'll see that Abelson and Sussman do have students who are confused with this so it's probably best using only one of these and since anonymous procedures are something you need to touch eventually it's obvious you want to teach the form with a explicit lambda instead of the syntactic sugar.

Anhydrite

Answer 2

It's simply a matter of style. In The Little Schemer the authors decided to explicitly declare procedures using lambdas, to make it clear that a function definition assigns a name to a procedure (which is just an expression with a value, like any other).

The other way to declare functions (without explicit lambdas) is completely equivalent, and it's just syntactic sugar. One could argue that the authors chose the more explicit syntax for pedagogical, not practical reasons.

Chronic

Answer 3

A lambda expression is a function literal, just like 3 (for example) is an integer literal. You could imagine a programming language where you couldn't use 3 in a larger expression, but had to define a variable and initialize it to 3. It would still work, but it would be inconvenient and get in the way. Most languages are like that with functions (they can just be defined once and then called), but functional languages let you treat functions like any other variable, including being able to refer to them literally.

Just like you use integer literal when you need a specific integer but don't need to bother with a variable, you use a lambda expression when you need a function but don't need to bother naming it.

A common use is with functions like mapcar which takes a function as an argument and applies that function to all the elements in the other argument. Sometimes you just want to throw a one-off function into that without needing to name it.

Just looking at that particular example, I would guess they're pointing out a difference between scheme and lisp (lisp does that somewhat differently).

Unhitch

Are u sure about that, any references maybe? – Villalba

Am I sure about what? What a lambda expression is? Yes. Look at any basic textbook on programming languages. – Unhitch

This doesn't answer the question which is asking about the why many favor the more verbose (define foo (lambda ...) instead of the more concise (define (foo ...) ...). – Conversational

Answer 4

I'm just finishing The Little LISPer myself. Initially, I was confused as to why they had employed this strange idiom. As you say, the latter is sugar for the former, and certainly looks neater, so what's the point in using anonymous functions everywhere?

From a pedagogic point of view, I think that it prepares the reader better for the final chapters, which cover currying, higher-order functions, the lambda calculus and so on. In particular, the derivation of the applicative-order Y-combinator requires the use of what you might call "unnecessary function-wrapping" in other contexts. By the penultimate chapter, you're so familiar with this procedure that deriving the Y-combinator is no more difficult than pouring a coffee or making some toast. Okay--not really, but I think that the style adopted by the authors certainly helps bring you closer to understanding this difficult idea.

Tensile