[plt-scheme] functional graphics

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Wed Jun 7 16:18:17 EDT 2006

Take a look at the image.ss teachpack and its documentation. You will 
then ask whether you can do the same for animation. Look at the 
world.ss teachpack. This is how we teach.

If you want apps, look at slideshow, which Robby recommended. Another 
one is FrTime, though it's more of a language at this point.

-- Matthias

On Jun 7, 2006, at 3:00 PM, knubee wrote:

> As I have been playing with graphics in Scheme I have been trying to
> wrap my head around the concept of "functional graphics" -- a phrase
> that originally seemed contradictory. Perhaps people here can help me
> understand it better.
> Usually in Scheme we try to emphasize the distinction between a value
> and an effect. One aspect is that functions always return the same
> value for same argument (that is, state of the system is theoretically
> unchanged after the computation). A variation is that values are
> separate from (possible) displayed representations: the value returned
> for (+ 2 3) differs from the 5 on the screen.
> Another aspect of this distinction is that, when we evaluate certain
> kinds of expressions, there may be both a value and an effect, but we
> can focus on "which is more important" to us for some particular case.
> So, for (+2 3) -- if we have to choose, we tend to care more about the
> fact that there is a returned value (and the fact that this can be an
> argument to another function) than  about whether (how) that value is
> presented onscreen. For typical imperative computer graphics, on the
> other hand, we care more about the effect and less about whether there
> are returned values (such as "done") after the command expression has
> executed. (As far as I know, graphics commands in strongly imperative
> languages don't even return values, so its not an option.)
> Functional graphics seems to blur this last aspect of the distinction.
> That is, we care about both the fact that compositions of image
> expressions return values -- AND the fact that they have effects. So,
> it is this compositional aspect of "functional graphics programming"
> that seems to be the "functional" part.
> Or is there some stronger interpretation of "functional graphics"? One
> where there is even less emphasis on effects?
> 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))
> etc.
> k
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Posted on the users mailing list.