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.

A letrec statement has the form (letrec ((name-of-recursive-proc body) (name-of-recursive-proc body) ... (name-of-recursive-proc body)) 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))

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

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 rgb-brightest. a. Rewrite this to make the helper local 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. > (rgb->color-name (rgb-brightest (map color-name->rgb (list "red" "green" "blue")))) > (rgb->color-name (rgb-brightest (map color-name->rgb (list "black")))) > (rgb->color-name (rgb-brightest (map color-name->rgb (list "red" "black" "green" "yellow")))) > (rgb->color-name (rgb-brightest (map color-name->rgb (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.

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 colors, or a non-list. Rewrite rgb-brightest so that it checks its preconditions (including that the list contains only RGB colors) before calling the kernel. Note that you can use rgb? to check if a value represents an RGB color.

Rewrite rgb-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.

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. You may use letrec or named let.

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

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.

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 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.

Here is one possible solution. Return to the exercise.

Here is one possible solution. Return to the exercise.

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 (rgb-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 Note that there is a hidden moral here: The procedures defined in a letrec can be mutually recursive. Return to the exercise.