Skip to main content

Laboratory: Local Procedures and Recursion

Summary: In this laboratory, we consider the various techniques for creating local recursive procedures, particularly letrec and named let. We also review related issues, such as husk-and-kernel programming.

Reference

A letrec statement has the form

(letrec ([name-of-recursive-proc-1 body-1]
         [name-of-recursive-proc-2 body-2]
         ...
         [name-of-recursive-proc-n body-n])
  expression
  expression
  ...
  expression)

This statement builds a new environment (that maps names to values), adds all of the named procedures to the environment, evaluates the expressions and then forgets about the environment. It is useful for temporarily creating local procedures, and for limiting access to kernels.

A named let is an alternative mechanism for defining recursive kernels. It can be used only when you want to define a single recursive kernel and call it immediately, and has the form

(let kernel ([name_1 exp_1]
             ...
             [name_n exp_n])
  body)

The named let tells Scheme to define a new procedure (whose name is kernel), with parameters that correspond to the names and whose body corresponds to body. It then immediately calls the new procedure with the given values.

In other words, named let is shorthand for the following:

(letrec ([kernel (lambda (name_1 ... name_2) body)])
   (kernel exp_1 ... exp_n))

Preparation

Make a copy of local-procs-lab.rkt, which contains the code for this lab.

Exercises

Exercise 1: The Brightest Color, Revisited

As the reading suggested, local kernels are particularly appropriate for checking preconditions. Local kernels are also appropriate for writing recursive helper procedures that take an extra parameter to accumulate a result.

For example, here is a helper-based definition of irgb-brightest.

(define irgb-brightest
  (lambda (colors)
    (irgb-brightest-helper (car colors) (cdr colors))))
(define irgb-brightest-helper
  (lambda (brightest-so-far remaining-colors)
    (cond
      [(null? remaining-colors)
       brightest-so-far]
      [(irgb-brighter? (car remaining-colors) brightest-so-far)
       (irgb-brightest-helper (car remaining-colors) (cdr remaining-colors))]
      [else
       (irgb-brightest-helper brightest-so-far (cdr remaining-colors))])))

a. Rewrite this to make the helper local using letrec and to name the helper kernel.

b. Test your procedure on a few simple lists of colors. For example, you might try some of the following.

> (irgb->color-name (irgb-brightest (map color-name->irgb (list "red" "green" "blue"))))
> (irgb->color-name (irgb-brightest (map color-name->irgb (list "black"))))
> (irgb->color-name (irgb-brightest (map color-name->irgb (list "red" "black" "green" "yellow"))))
> (irgb->color-name (irgb-brightest (map color-name->irgb (list "yellow" "red" "black" "green"))))

c. When you are done, you may want to compare your answer to a sample solution contained in the notes on the exercise.

Exercise 2: Safely Computing the Brightest Color

The procedure given above, and your rewrite of that procedure, will fail miserably if given an inappropriate parameter, such as an empty list, a list that contains values that are not integer-encoded RGB colors, or a non-list. Rewrite irgb-brightest so that it checks its preconditions (including that the list contains only integer-encoded RGB colors) before calling the kernel.

Note that you can use irgb? to check whether a value represents an RGB color.

Exercise 3: Computing the Brightest Color, Revisited Again

Rewrite irgb-brightest-helper using a named let rather than letrec. (The goal of this exercise is to give you experience using named let, so you need not check preconditions for this exercise.)

When you are done, you may want to compare your answer to a sample solution contained in the notes on the exercise.

Exercise 4: Tallying Bright Colors

Here is the start of a procedure that tallies the number of bright colors in a list.

(define tally-brights
  (lambda (lst)
    (tally-brights-helper 0 lst)))

(define tally-brights-helper
  (lambda (tally remaining)
    ...))

a. Finish the definition.

b. Rewrite the definition of tally-brights to make the helper a local procedure using a named let.

For Those With Extra Time

Extra 1: Tallying Bright Colors, Revisited

Rewrite tally-brights (from Exercise 4) to use whichever of letrec and named let you did not use in that exercise.

Extra 2: Reflection

You have now seen two examples in which you’ve employed two different strategies for building local helpers, one that uses letrec and one that uses named let.

Reflect on which of the two strategies you prefer and why.

Extra 3: Alternating Lists

A list of colors is a bright-dark-alternator if its elements are alternately bright colors and dark colors, beginning with a bright color. A list of colors is a dark-bright-alternator if its elements are alternately dark and bright, beginning with a dark color. (We say that the empty list is both a bright-dark-alternator and a dark-bright-alternator.)

a. Write a predicate, colors-alternating-brightness?, that determines whether a non-empty list of colors is either a bright-dark-alternator or a dark-bright-alternator. Your definition should include a a letrec expression in which the identifiers bright-dark-alternator? and dark-bright-alternator? are bound to mutually recursive predicates, each of which determines whether a given list has the indicated characteristic.

(define colors-alternating-brightness?
  (lambda (colors)
    (letrec ([bright-dark-alternator?
              (lambda (colors) 
                ...)]
             [dark-bright-alternator?
              (lambda (colors) 
                ...)])
      ...)))

When you are done, you may want to compare your answer to a sample solution contained in the notes on the exercise.

b. Here are a few lists of colors. For which do you expect the colors-alternating-brightness? predicate to hold?

(define RGB-WHITE (color->rgb "white"))
(define RGB-BLACK (color->rgb "black"))
(define RGB-RED (color->rgb "red"))
(define RGB-BLUE (color->rgb "blue"))
(define RGB-YELLOW (color->rgb "yellow"))
(define sample0 null)
(define sample1 (list RGB-WHITE))
(define sample2 (list RGB-BLACK))
(define sample3 (list RGB-WHITE RGB-BLACK))
(define sample4 (list RGB-BLACK RGB-WHITE))
(define sample5 (list RGB-BLACK RGB-BLACK))
(define sample6 (list RGB-WHITE RGB-BLACK RGB-WHITE))
(define sample7 (list RGB-WHITE RGB-BLACK RGB-WHITE RGB-BLACK RGB-WHITE))
(define sample8 (list RGB-RED RGB-YELLOW RGB-BLUE RGB-WHITE RGB-BLACK))

c. Check your answers experimentally.

Notes

Notes on Exercise 1: The Brightest Color, Revisited

Here is one possible solution.

(define irgb-brightest
  (lambda (colors)
    (letrec ([kernel
              (lambda (brightest-so-far remaining-colors)
                (cond 
                  [(null? remaining-colors)
                   brightest-so-far]
                  [(irgb-brighter? (car remaining-colors) brightest-so-far)
                   (kernel (car remaining-colors) 
                           (cdr remaining-colors))]
                  [else
                   (kernel brightest-so-far 
                           (cdr remaining-colors))]))])
      (kernel (car colors) (cdr colors)))))

Return to the exercise.

Notes on Exercise 3: Computing the Brightest Color, Revisited Again

Here is one possible solution.

(define irgb-brightest
  (lambda (colors)
    (let kernel ([brightest-so-far (car colors)]
                 [remaining-colors (cdr colors)])
            (cond
              [(null? remaining-colors)
               brightest-so-far]
              [(irgb-brighter? (car remaining-colors) brightest-so-far)
               (kernel (car remaining-colors)
                       (cdr remaining-colors))]
              [else
               (kernel brightest-so-far
                       (cdr remaining-colors))]))))

Return to the exercise.

Notes on Extra 3: Alternating Lists

Once bright-dark-alternator? and dark-bright-alternator? are written, the definition is fairly straightforward. A non-empty list of colors has alternating brightness if it’s not empty and it’s either a bright-dark-alternator or a dark-bright-alternator.

      (and (not (null? colors))
           (or (bright-dark-alternator? colors)
               (dark-bright-alternator? colors)))

Each definition is also fairly straightforward. A list is a bright-dark-alternator if it is empty or if the car is bright and the cdr is a dark-bright-alternator.

             (bright-dark-alternator?
              (lambda (colors) 
                (or (null? colors)
                    (and (irgb-bright? (car colors))
                         (dark-bright-alternator? (cdr colors))))))

The definition of dark-bright-alternator? is so similar that we will not provide it separately.

Putting everything together, we get

(define colors-alternating-brightness?
  (lambda (colors)
    (letrec ([bright-dark-alternator?
              (lambda (colors)
                (or (null? colors)
                    (and (irgb-bright? (car colors))
                         (dark-bright-alternator? (cdr colors)))))]
             [dark-bright-alternator?
              (lambda (colors)
                (or (null? colors)
                    (and (irgb-dark? (car colors))
                         (bright-dark-alternator? (cdr colors)))))])
      (and (not (null? colors))
           (or (bright-dark-alternator? colors)
               (dark-bright-alternator? colors))))))

Note that there is a hidden moral here: The procedures defined in a letrec can be mutually recursive.

Return to the exercise.