=====
CS 111 - Week 5 Lecture 1 - 2026-09-22
=====
=====
TODAY WE WILL:
=====
* announcements
* intro big-bang's on-key clause
* intro to itemization data
* prep for next class
=====
* if interested: can see the set of functions setting
up event handlers for big-bang when the world type
is string (code is on the public site, recording on
the Canvas site)
* on Canvas: go to Modules,
see the new "CS 111 recordings" section
* on public site: go to in-class examples,
go to the "POST Week 4 - Lecture 2 EXTRA example"
section (right above the Week 4 Lab section)
=====
* should be working on Homework 4!
* at-least-first attempts due by 11:59 pm Friday, Sept. 25
=====
big-bang's on-key clause
=====
* another of the big-bang function's optional clauses is:
on-key
* you can give on-key a function that specifies how big-bang's
world should change on the event of a user typing a key
on the keyboard
* on-key's function is expected to be the name of a function
that expects TWO arguments,
the type of the current world and a string,
and that returns the type of the current world
* when a key is typed, then,
big-bang CALLS this function with the current world value
and a string representing the key typed,
and the result of that function call is the NEW value
of the world
* see posted examples to see function change-elevation, which
can work with a big-bang expression's on-key clause to change
a penguin's elevation by typing up- and down-arrow keys
=====
itemizations
=====
* HtDP/2ed section 4.5:
"An interval distinguishes different subclasses of numbers;
an enumeration spells out item for item the useful elements in
an existing class of data.
Data definitions that use ITEMIZATIONS *generalize* intervals
and enumerations.
They allow the COMBINATION of any existing data types (defined
elsewhere) with each other and with individual pieces of
data."
* Data definition?
...we've been informal about these so far;
we could be one step more formal and say that we'll call
a data definition a comment using this format:
; DATA DEFINITION
; a DesiredType is [and describe it]
* CS 111 class style:
Unless the data definition is for a built-in Racket data type,
write your new defined type in CamelCase starting with
an uppercase letter
* CS 111 class style:
IF you include a data definition comment like the above,
you can then use that informally-defined type in
function signature comments that follows this data definition
...if a data definition is for an itemization,
it would take THIS form:
; DATA DEFINITION
; a DesiredType is one of:
; * possibility
; * possibility
; ...
* OK, you only need the list part above for
itemization data, and sometimes it is useful for enumeration data
* for example:
; DATA DEFINITION
; a NumOrF is one of:
; * #false
; * a number
* for a function driven by itemization-style data, can you see that you
might need a cond with a branch for each item in the
itemization's data definition?
for tests? ah, you might need more! depends on the items
in the itemization!
* should have at least 1 per itemization item,
* BUT if that item involves interval or intervals, you might need
more -- such as boundary tests!
* and if an item involves enumeration data, might need one for
each,
* and if the function you are writing specifies exceptions,
you should test for those also;
=====
ASIDE: built-in function equal?
=====
* another boolean function to compare for equality
* can you see how, for a function expecting itemization
data, you might want to compare it to a value, but you
might not reasonably yet know its underlying type?
* we know that:
* = can be used to see if arguments of type *number*
have the same value;
(= 3 4) ; #false
* string=? can be used to see if two arguments of
type *string* have the same value;
(string=? "moo" "Moo") ; #false
* boolean=? can be used to see if two arguments of
type *boolean* can have the same value;
(boolean=? #true true) ; #true
* image=? can be used to see if two arguments of
type *image* can have the same value;
(image=? (circle 10 "solid" "red")
(circle (+ 5 5) "solid" "red")) ; #true
* AND notice: any of the above will give an error if
used with arguments of a type they do NOT expect;
(= 3 "moo") ; causes an error, "moo" is a string, not a number
(= 3 4) ; no error, just returns #false
* but! consider an instance of NumOrF that we defined
earlier --
how can we see, for example, if it is equal to #false
without causing an error if it happens to be a number?
* in THIS case, we might NEED a less-type-sensitive
equality-comparison function!
* that function is equal?
* equal? expects two arguments of ANY type,
and returns #true if they have the same value,
and #false otherwise -- so,
(equal? #false 27) ; just returns #false, not an error
* WHY don't we just always use equal? then?
* this is a bit subtle, but: if your function ALWAYS
expects a particular type, using the more-specific
test-for-equal function returns a possibly-better
error message;
so, if your function expects numbers, using =
causes an expects-a-number error, which might be
useful!
=====
SO... if an itemization type has items of different data types
amongst its items, you can use equal? in a cond branch
to compare to a parameter of that
itemization type without getting a syntax error...
=====
* will finish our example of a function driven by itemization-syle
data, double-it, on Thursday,
then proceed to LISTS,
which are our first DATA STRUCTURE,
and, while a built-in data type in BSL Racket,
can also be said to be itemization-style with a TWIST...