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

You can do this, and I pointed this out to John privately. -- Matthias



On May 11, 2009, at 2:18 PM, Nadeem Abdul Hamid wrote:

> 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
>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme