[plt-scheme] Re: Continuations memory accumulation problem

On Tue, Mar 16, 2010 at 12:38 AM, Anthony Cowley <acowley at seas.upenn.edu> wrote:
> 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.

    Indeed your code is quite a nice example of purely functional
programming. And indeed you don't use any kind special syntax nor
lets, but just function composition.
    But I wonder how would you write some more complicated code like:
if robot smells 'food, try turning until you are facing what it's
smelling, or it has turned enough times. This doesn't work as easy as
just chaining some actions. You need some syntactic sugar.

    Answer: I'm stupid. :) I've looked again at your code (snippet
below) and I finally get it how. :) It's dead easy.

    Your code:
~~~~
(define wander (do-when (compose null? robot-action)
                       (do-if (λ (_) (= (random 10) 0))
                              assume-random-heading
                              move-ahead)))
~~~~

    My try:
~~~~
(define look-around-for-food
    (do-if (smell food)
        (compose
            do-grab
            (do-while (compose not (feel food)) 4 turn-left))
        do-nop))
; the 4 there is this the maximum number of iterations, to allow me to
stop when turning too many and no food was found
~~~~

    As I said: I never stop learning. :) (And I've actually thought I
knew a little bit of functional programming... I was kind of wrong...
:) Thanks for opening my eyes. :) )


>>    (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.

    Indeed Shriram has given me some good pointers on how I could make
my laboratory better. (I've switched from the usual way I've done this
(boring synthetically problems) towards something more practical
projects. And I've also recommended the HtDP book as a nice
introduction to Scheme and functional programming.)

    (My desire is not to emphasis on GUI programming, but I thought
that starting from this robot game-like project I would engage my
students more. (Almost all of them want to program games :) ) So I
just give them something with a nice graphical user interface as a
starting point and let them experiment (through my guiding).)


>>    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.

    Yup I got it now. I always thought that a DSL in Lisp is 75%
syntax (macro) constructs and 25% (or less) functional combinations.
But I think you proved me wrong. This particular DSL I think can be
100% functional. Thanks again.


> 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).

    Indeed this was my initial intent. Starting with a classic
imperative programming style (not even OO), in which we just alter
some local state, and the progressing towards more functional
constructs.

    (The continuations are still need to be in there in the background
as I need the graphical user interface to let the students see what is
happening. And unfortunately the graphical user interface insists that
on refresh and on timer notifies it calls my code from inside it's
event loop and it just waits me to return control... So continuations
is the best way in which I was able to interleave code from multiple
robots and the graphical user interface.)


> 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.

    Now this I don't get it: "as you don't want mushy designs"
(English is not my native language).

    So you say that an incremental change from imperative programming
towards functional programming is not right as the examples would be
littered with a bit of both? Thus you are suggesting that at each step
I should redesign the entire thing with the new concepts.


>>    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

    Maybe you're right about the decoupling of the robot and world.
They should be separated by a clear interface.

    Thanks again! And thanks for the time! Talking with you was really
useful for me!
    Ciprian.