[plt-scheme] I miss end-of-time...

On Mar 12, 2010, at 11:59 AM, Carl Eastlund wrote:

> It doesn't say it directly; functions say things directly by returning
> values.  "end-of-time" says it very indirectly; I forget if it fails
> to return, and uses a continuation to jump out of the big-bang loop,
> or if it uses a mutable channel to grab the latest world value and
> return that,

I don't care about the implementation behind the scenes.  From the perspective of someone using it, it says "Return the following value from the animation."

> Furthermore, I don't consider a natural number to be a natural model
> for your program; it's merely a convenient shortcut.  You have an
> entire game state -- stop on key press -- that isn't represented at
> all.

If you think of that as part of the game, yes.  It could also be argued, however, that once you've stopped the game, there IS NO "game state", so you don't need to represent the state in which the game is "stopping"; it's like asking what a recently-deceased person is thinking about.

In other words, if you start with the axiom that the only way to end an animation is "stop-when", then indeed you need a way to represent the state between "decided to stop" and "stopped".  If you don't accept that axiom, but rather the alternative axiom that the "state" of an animation only exists while the animation is running, then there is no such state, so you don't need to represent it.

>  If you're concerned about keeping your function inputs simple,
> bear in mind that the event handlers plus "live" world renderer only
> ever input a "live" world (i.e. a natural number) and the "dead"
> renderer only ever inputs a "dead" world (false).

Yes, that makes good sense, and I'll recommend it to my students once they know about union data types.  Which won't be for another two weeks or so.

> Certainly, it can be more convenient to use end-of-time, and I can't
> argue for what will or won't be "confusing" for your students, you may
> know that better than I do.  On the other hand, in giving up
> functional programming, you give up a lot of the HtDP approach.

Would you say the "return" statement in Java is "giving up functional programming"?  How about "try"/"catch"/"throw"?

> How do you test a function that uses end-of-time?

Yes, that has been a problem in the past because of the way end-of-time was implemented: I had students quite reasonably putting "(end-of-time 17)" as the right answer in a check-expect, and the animation ended before it could begin.  I hope that since "stop-with" is (apparently) just a passive data structure recognized by "big-bang", that problem has gone away now.  I haven't tried it yet, though.


Stephen Bloch
sbloch at adelphi.edu