[plt-scheme] FrTime implementation

From: Gregory Cooper (greg at cs.brown.edu)
Date: Tue Jan 8 12:01:29 EST 2008

Hi Dave,

> Sorry for the delay, I seem to be trying to do too many things at once...

No worries.  ;-)  However, did you get my last message (written on
Dec. 9 and copied to the plt-scheme list), in which I described a
different implementation strategy?  I'd be happy to resend and/or
elaborate on it, and I would strongly recommend taking that approach,
which doesn't use any lifting.

> Firstly, I still seem to be getting the case where both time behavours are
> expressed at the same rate - i.e. in the example below the action given
> the seconds is called as many times as the milliseconds one, implying that
> my list is not created properly.

This is what it means to lift over a list.  The A and B change at
different frequencies, but their "union" changes whenever either of
them changes.

If you're rendering a scene, it's easiest to start from an empty
buffer and draw everything.  Otherwise, you'd need somehow to "undraw"
just the B and redraw it in its new state.  Sorry if you expected it
to do something more clever.  :-)

> Also, I just wondered what vn is - the argument to the procedure given to
> compound lift. As it's used to get the values from the behaviours, I'm
> guessing it's the all important procedure which actually expresses the
> lifting? Why does it also need to be called on each of the elements of the
> draw list?

'v-n' is an abbreviation for 'value-now'; it returns a behavior's
current value (and passes non-behaviors through unchanged).  It needs
to be called on each element of the list because each element could be
a behavior.  In compound-lift, the 'v-n' that gets passed in does some
extra bookkeeping, so you need to use it instead of the standard

> Do the calls inside the draw list procedure which do the actual work have
> to be lifted (printf in this case) is it enough to just use v-n to extract
> the value from the behaviour? I've had some unpredicable behavour when
> I've used procedures from my binary extensions here, but I'm probably
> missing something simple.

The compound-lift takes care of re-evaluating the procedure whenever
something in the list changes.  The procedure itself should only need
to extract current values and then do whatever it wants with them.  If
you've encountered unexpected behavior with compound-lift, I'd be
interested in the details so I can try to reproduce it.


Posted on the users mailing list.