[plt-scheme] functional graphics

The only effect you need is at the end to display the image. Until that
point, its just functional composition. There are a ton of packages
that do this kind of thing. From our world, you might want to check out
Slideshow and there are bunch more mentioned in the related work
section here:

  http://people.cs.uchicago.edu/~robby/pubs/papers/jfp2005-ff-color.pdf

(there's a bw version on my web page if you want that instead).

You might also want to check out the image.ss and world.ss teachpacks.
There's docs in Help Desk about them, and exercises on Matthew Flatt,
Matthias Felleisen's and my web pages (holler if you can't find them).

Robby

At Wed, 7 Jun 2006 21:00:14 +0200, 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