[racket] fruit flies

From: Danny Yoo (dyoo at cs.wpi.edu)
Date: Mon Sep 12 21:51:12 EDT 2011

> Danny: why do you think that changing those elements does less work
> than what happens when you create a new scene with the 2htdp/universe
> version of this program?

The diff-based approach I'm taking in web-world makes it easier to
preserve pieces of state embedded in the dom, without the user having
to know about it.  My point of comparison isn't really versus
2htdp/universe's performance: it's versus the functionality of my old
jsworld library from Moby.

One of the things I learned from the previous time I implemented a
world+dom library is that there's a tremendous amount of state in the
DOM that I don't want to explicitly construct.  Expressing to-draw in
terms of diffs is nice precisely because the stuff you don't mention
stays the same.

Let me mock up a quick example to demonstrate:

    http://hashcollision.org/whalesong/examples/field2/field2.html

The source code is
http://hashcollision.org/whalesong/examples/field2/field2.rkt, with
its template http://hashcollision.org/whalesong/examples/field2/index.html.
The program demos two sources of events: clock ticks, and button entry.


I could not cleanly write this program in my old jsworld library.


In old jsworld, my to-draw handler consumed xexpr representations of
the dom.  What makes this problematic is that it's not a complete
representation of the dom: there's state in the text field's cursor
position.  That state needs to be somehow represented in the to-draw,
and that state needs to be stable across world updates: if it weren't,
it wouldn't be fun to try to type text into the field, because the
cursor would otherwise jump back to the beginning of the text field on
every clock tick!

Although I could work around that by representing cursor state in my
world, the state of the view is something that isn't really supposed
to be part of the program model.


Posted on the users mailing list.