[racket] question about naming convention

On May 19, 2012, at 11:01 AM, Danny Heap wrote:

> I wrote a small module for the convenience of my students in
> manipulating image color-lists in 2htdp/image.

You might take a look at the picturing-programs teachpack, which does a lot of this stuff already.  In particular, it provides

map-image (which applies a specified function to each pixel of an image, theoretically in parallel, producing an image the same size and shape)
build-image (which applies a specified function to each ordered pair in {0..width-1) x (0--height-1), producing an image of the specified size and shape)
fold-image (which applies a specified function to each pixel of an image successively, with the result of each being fed into the next).

There are several variants of these.  For example, map-image checks whether its function argument has arity 1 or 3: if 1, it gives that function just the color, and if 3, it also gives it the (x,y) coordinates, so you can do location-dependent manipulations.

>  I want them
> to be able to create a new color one band at a time, and in my draft I
> have, for instance:
> 
> ; new-red : number color -> color
> ; Produces a new color by replacing
> ; the red intensity of col by val.
> (define (new-red val col) ...)

That's a very different approach, but I think it's motivated by the same pedagogical impulse -- I wanted students to be able to do pixel manipulation before they knew about structs -- that led me to write map3-image and build3-image.  These take 3 separate function arguments (one producing the red component, one green, and one blue); in addition, map3-image gives its functions the red, green, and blue components of the input pixel separately rather than passing in a color struct.

In practice, I've found that map3-image and build3-image are a pain to use in the classroom, because you have to write three separate functions before you can use them.  So what I did this semester was introduce "make-color" very early -- the second week of the semester -- so students could use build-image immediately, and so they would get a lot of practice BUILDING color structs before they ever had to take one apart.  I postponed map-image until they had seen color-red, color-green, and color-blue.  That's not ideal either, but I think it worked reasonably well.

> Is there a convention for naming, rather than new-???, that makes it
> obvious that there is no mutation going on?

We've been discussing that, in connection with the plan for define-struct (in student languages) to provide such "functional setters" for ALL structs, not just colors.  No resolution yet, AFAIK :-(

> I also included an image comprehension, for/image, to suppress the
> details of image->color-list, followed by color-list->bitmap, in
> transforming an image.  I read some of the discussion on preferring
> map over the for- comprehensions, but I want to allow my students to
> transform colors at the expression level, without the overhead of
> functions, named or anonymous.  Are there grievous pedagogical
> implications I should be aware of?

I don't know about "grievous", but I think this sort of image manipulation gives students the motivation to practice writing (typically very short and simple) functions, which is a good thing.  I have them practice writing expressions at the "image" level for a week or so before starting them on functions, but then I tell them "Get used to writing functions: you'll write at least a hundred of them in the remainder of the semester."

If you have suggestions for other image utilities like this, talk to me off-list and we can include them in picturing-programs, which has the advantage of being bundled with DrRacket so there's no separate installation procedure.

Stephen Bloch
sbloch at adelphi.edu