[plt-scheme] functional graphics

On 6/7/06, knubee <knubee at gmail.com> wrote:
> Oh, I'm thinking of examples like this: STACK as a procedure that
> takes 2 images as arguments and a) displays image1 on top of image2,
> and b) returns a value that can be used as an argument by another
> invocation of STACK (or other image procedures).
>
> (stack image1 image2) -> value and effect
>
> (stack image1
>          (stack image2 image3))

Think about the following DrScheme interaction:

> (+ (+ 1 2) 3)
6

We compute with +, and see "6" as a result.  We might conclude that +
prints its result on the screen.  But on closer analysis, we would
expect to see a "3" as well, because (+ 1 2) produces 3.  So we must
conclude that + does not print its result.  Where does that "6" at the
end come from?  The answer is that the prompt itself -- the
interactions window, or the mzscheme REPL -- prints out the result of
any computation, even when that computation has no "effects" of its
own.

Now let's apply that intuition to image manipulation.  Let's say we
have defined some variables: FISH-IMAGE and CAT-IMAGE and DOG-IMAGE,
each containing data representations of images.  They have not been
drawn anywhere yet, but if they were they would look like a fish, a
cat, and a dog respectively.

(stack (stack FISH-IMAGE CAT-IMAGE) DOG-IMAGE)

What do we expect to see after this?  I would expect to see a fish, a
cat, and a dog.  If stack printed its result, we would see the fish
and cat twice; once for the inner "stack" call and once for the outer
one.  So stack shouldn't print every time.  Instead, like with +,
stack only produces data.  The interaction prompt prints the final
result.

That's how functional graphics work.  Of course one can always add
functions with effects - just like programmers have print for
displaying numbers and strings, there can always be a draw function
for displaying images.  But the basic tools don't need effects.

-- 
Carl Eastlund
"Cynical, but technically correct."