[plt-scheme] Re: Continuations memory accumulation problem

On Mon, Mar 15, 2010 at 5:42 PM, Ciprian Dorin, Craciun
<ciprian.craciun at gmail.com> wrote:
>    About a purely functional robot (one that only creates new robot
> states and never alters them) would be ideal. Unfortunately the code
> would be filled with a lot of `let`'s after each operation just to
> capture a new state. Either that or a lot of small functions that
> delegate one another. (Although I think I could just hide all these
> state exchanges behind some syntax trickery.)
>    (Don't get me wrong I like the purely functional programming
> style, as I'm accustomed with Erlang where this is the only way, I
> just don't think this suits best here.)

The code I sent is purely functional and does not have very many lets
at all, or any macros. Admittedly, it lends itself to at least two
levels of understanding: a superficial understanding that permits the
addition of new behaviors, and a deeper understanding of how much of
the plumbing manages to be invisible (foldl + a monad). So, it's not
the simplest thing possible, but I think the continuation-based
approach is a bit worse in this regard.

>    (I forgot to mention the purpose of my simulator: I want to give
> my students an assignment to program some AI for the robots and this
> way introduce them to Scheme. Indeed that for the moment my robot is
> not quite "functional style" but I try to take it one step at a time,
> from "procedural, or OOP style" towards "functional style". That's why
> my accent here is on the control programming and on the efficiency of
> the entire simulation framework.

The HtDP guys on this list can advise you better than I on
progressions between programming styles. Personally, I think GUI
design is great for demonstrating classes and objects, and PLT has
this pretty well nailed down, but I defer to the experts here.

>    Maybe it will be a nice (advanced) assignment to ask my students
> to modify the source code (about 500 lines with a lot of spaces) to
> implement purely functional world and robots. (I do have multiple
> robots.)
>
>    About the DSL, indeed such a thing emerges (this was another
> assignment I wanted to give out).

There's really very little code in the simulator I sent (~70 lines, I
think), and the DSL emerges pretty organically based on only a handful
of ways to inspect or change the state-carrying structures, the two
conditional combinators, and the idea of folding a list of independent
behaviors.

If you want to do things both ways, then my choice would be to avoid
all typically functional constructs in the first OO simulator (no
continuations or anything that I've written, along with plenty of
mutation of private fields). I think porting between OO and functional
is a tad suspect as you don't want mushy designs to be your exemplars
of different programming techniques.

>    I envisage the following modules:
>    * world -- contains only the logic behind the world and robots
> (core operations that update the environment (by update we could also
> understand creating new states));
>    * library -- contains the code that loads tiles (the map) and
> other data-files (image files, etc.)
>    * vizualization -- contains the source code that only displays the
> update world;
>    * dsl -- syntaxes and functions that build upon the core
> operations and enrich the expressiveness;
>    * proxies (could be implemented) -- allows to attach a local robot
> to a remote world or the other way around;
>
>    Is this modularization Ok? Do you see something different?

I think this sounds great; the minor changes I'd make are to separate
the robot definition from the world definition and add a top-level
module for running simulations.

Anthony