Example where letrec/letrec* is better than let with internal defines or named let ?

Question

The two examples Kent Dybvig gives in The Scheme Programming Language for letrec and letrec* are:

(letrec ([sum (lambda (x)
             (if (zero? x)
                 0
                 (+ x (sum (- x 1)))))])
   (sum 5))

and

(letrec* ([sum (lambda (x)
            (if (zero? x)
                    0
                (+ x (sum (- x 1)))))]
         [f (lambda () (cons n n-sum))]
         [n 15]
         [n-sum (sum n)])
  (f))

The first can also be written as a named let:

(let sum ([x 5]) 
  ((lambda (x)
                 (if (zero? x)
                     0
                     (+ x (sum (- x 1))))) x))  

and the second can be written as a let with internal defines:

(let ()
  (define sum  (lambda (x)
               (if (zero? x)
               0 
                   (+ x (sum (- x 1))))))
  (define f (lambda () (cons n n-sum)))
  (define n 15)
  (define n-sum (sum n))
  (f))

The letrec/letrec* forms don't seem any more concise or clearer than the named let or let with internal defines forms.

Can someone show me an example where letrec/letrec* does improve the code or is necessary instead of named let or let with internal defines.

Answer 1

Yes, the first example can be rewritten using a named let, but note that there is no need for the lambda form in there:

(let sum ([x 5])
  (if (zero? x)
    0
    (+ x (sum (- x 1)))))

This kind of transformation is a bit misleading -- it is fine to do in case you're defining a single "looping function" (in the broad not-only-tail-recursive sense) and immediately use it on a known input. But usually, when you see examples such as the one you gave, the intention is to show the definition and use of a local function, so it's possible to do this transformation only because it's a for-demonstration toy example.

Secondly, note that a named let is usually not a primitive form -- the implementation strategy that practically all Scheme implementations use is to have that form expand into a letrec. It is therefore still a good idea to understand letrec if you want to understand named-lets. (And this is a fundamental feature: being able to do self-reference via a recursive scope.)

Finally, the example that you gave with internal definitions is similar to named-lets: it is a syntactic sugar that expands into a letrec (which can be either a proper letrec or a letrec* with R5RS, and required to be a letrec* in R6RS). So in order to understand how it works, you need to understand letrec. Note also that some implementation that use strict letrec would also barf at your second example, and complain that sum is undefined. It is this syntactic sugaring that is behind the main argument for the letrec* semantics that was adopted in R6RS: many people like using internal definitions, but then there is a problem that toplevel definitions allow using previous definitions but internal definitions are less convenient in an unexpected way. With letrec*, internal definitions work like toplevel ones. (More precisely, they work like toplevel barring re-definitions, which means that they're actually like module-toplevel definitions.)

(Note also that (a) both Racket and Chez extend internal bodies to allow definitions and expressions to be mixed which means that the expansion is as straightforward.)