Functional Problem Solving (CSC 151 2014F) : Labs
Primary: [Front Door] [Schedule] - [Academic Honesty] [Disabilities] [Email] - [FAQ] [Teaching & Learning] [Grading] [Rubric] - [Calendar]
Current: [Assignment] [EBoard] [Lab] [Outline] [Reading]
Sections: [Assignments] [EBoards] [Examples] [Handouts] [Labs] [Outlines] [Readings]
Reference: [Setup] [VM] [Errors] - [Functions A-Z] [Functions By Topic] - [Racket] [Scheme Report (R5RS)] [R6RS] [TSPL4]
Related Courses: [Davis (2013F)] [Rebelsky (2014S)] [Weinman (2014F)]
Misc: [Submit Questions] - [SamR] [Glimmer Labs] [CS@Grinnell] [Grinnell] - [Issue Tracker (Course)]
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-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))
Make a copy of local-procs-lab.rkt
, 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
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.
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.
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.
(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.
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 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.
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)))))
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))]))))
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.