[plt-scheme] Re: Continuations memory accumulation problem

On Tue, Mar 16, 2010 at 2:34 AM, Ciprian Dorin, Craciun
<ciprian.craciun at gmail.com> wrote:
>    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.

Be careful here! It's not syntactic sugar you're after, it's support
for a different kind of action. If you want an action whose execution
spans multiple simulation time intervals, then you need to carry that
state with you. You're also running into a critical decision in the
simulation design: what values can a controller directly affect. The
usual example of this is position: it is unrealistic for a controller
to directly output a position, as that would allow an agent to
teleport; it is unrealistic for an agent to directly output a
velocity, which can be integrated to control position, as that would
allow for infinite acceleration; it is a pain to only allow an agent
to directly control its acceleration, as the system is now harder to
model. So you pick your poison. An easy way out is to directly control
position with the proviso that a robot can only take one step per time
step; the implicit assumption is that you have a continuous controller
that enables you to transition between these discrete states.

These questions apply to your situation in that you must decide if the
robot can turn any amount in one time step. If you don't want a robot
to be able to, say, turn 180 degrees in one step, then you must
consider how to implement a more metered movement.

The least invasive option is to say that a robot may turn no more than
x degrees per time step, let's say 10. Then, if the robot smells
something to its left, it may turn up to 10 degrees in that direction.
The next time step, the robot will still smell something in that
direction, and can turn some more. This can be a purely reactive
controller.

If you want to include a planning component (i.e. propose to perform
an action that will take some time to complete, and not re-plan every
time step), then you will want to carry some additional state along
with the robot. Your idea of allowing the robot 4 turns to do
something could be in this category.

My suggestion to you is that you emphasize reactive behaviors and
allow minimal planning. The reason is that most people tend to do just
the opposite, and bundle all kinds of state along with their behaviors
as it seems like the easiest way forward. That strategy will typically
crumble under its own weight as the resulting composite behavior ends
up a big, tangled monolith, rather than a collection of decoupled,
testable components. Programming the behavior functionally makes this
clear, as the accumulation of state is made more explicit and even
burdensome to the programmer.

So, to be concrete: start with reactive behaviors for avoiding
obstacles and picking up items. Then add in a path planning component
that can store progression along the path in the robot state. Finally,
fuse these layers so that you have reactive components modulating the
planned behavior.

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

I apologize; I used useless, vague phrasing to describe a lack of
focus. Fitting, but unhelpful. What I meant was that OO code that is
designed to be transliterated into a functional style is often awkward
and unidiomatic. I'm just asking that the OO simulator be done
honestly, and not hindered by any plans to port it. There are lots of
great OO simulation frameworks out there, and most don't look at all
functional.

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

That's just my opinion, I'm sure others would disagree. Let the
commonalities between the approaches arise on their own. You could
write minimal simulators in various styles and let the students flesh
them out, then review them in class to see what worked well in each
approach.

Anthony