Computers obviously not harmful (was: Re: [plt-scheme] Computers considered harmful)

On May 11, 2009, at 1:10 PM, John Clements wrote:
> On May 11, 2009, at 1:45 AM, Noel Welsh wrote:
>> On Fri, May 8, 2009 at 8:07 PM, John Clements <clements at brinckerhoff.org 
>> > wrote:
>>> To be somewhat more specific: imagine using an FRP model to  
>>> program a robot
>>> to add one to each element of a list:  The robot's state would  
>>> probably
>>> include 'what element I'm visiting', and perhaps an 'add one'  
>>> operation.
>>> The point is that even a purely functional solution is placed into  
>>> a robot
>>> framework that turns it into a sequence of mutations.
>>
>> Depends upon the level of abstraction. Imagine a robot with a binary
>> sensor pair? and two actions, head and rest...
>
> Yes, I'm imagining it: the solution is still going to look  
> imperative, right?
> e.g.:
> (define (react state)
>  (cond [(empty-sensor? state) (return counter)]
>        [else (set counter (+ counter 1)) (move-to-cdr)]))
> It appears to me that applying the "robot model" to introductory  
> programming is not going to help you make the crucial bridge to  
> algebraic programming.


I don't understand... couldn't you thread through sensor and behaviors  
as well as an abstract world structure? Have react be:
    react : sensors world -> behavior world
It takes the current state of the sensors, some abstract data, the  
'world', and produce a behavior (which may be atomic, or a combination  
of simpler behaviors) and a new 'world'. The possible behaviors are a  
mixed collection of structures describing things that can be effected  
through the robot's actuators.

Then have something like:

(define (react sensors ctr)
   (cond [(empty-sensor? sensors) (values no-behavior ctr)]
      [else (values '(move-whatever) (+ counter 1))]))

What's wrong with that?

I'm not sure I understand the original example of programming "a robot  
to add one to each element of a list"... the things the robot would be  
doing are somewhat different than abstract operations on lists. Of  
course if you need to remember something about the history of what the  
robot has seen, then the 'world' above would be some data structures  
involving lists, but then to manipulate that, you use the standard  
functions/design recipe for dealing with lists and structures. As far  
as the interaction with the robot, it is a pure function from sensors  
to behaviors...

Perhaps I misunderstand, and what you mean by 'counter' is something  
that has a physical realization in the robot. But in that case, then  
there would be a 'behavior' that effects the side-effect of  
incrementing the counter (hidden in them implementation of the  
counterpart of 'big-bang'), and your react function would just produce  
that behavior object, and not explicitly have to deal with updating  
the counter in an imperative style.

The reason I'm asking is one of the things I hope to work on this  
summer is to put together a teachpack for HtDP that would interface  
with the Myro robots (http://wiki.roboteducation.org/Learning_Computing_With_Robots 
), by extending the model of worlds with additional stuff to deal with  
the robot...

--- nadeem