LOGO-L> Re: Logo with parallel processes vs. ToonTalk

["Ken Kahn" <KenKahn@ToonTalk.com>]

Brian Harvey wrote in message <73ph80$lp$1@agate.berkeley.edu>...
>"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>>And yes, languages like ToonTalk can have 100,000 processes each doing
>>procedure calls.
>
>Now I'm really lost.  You argued that procedure calling is bad because
>they require stack frames, whereas processes are good because they don't.
>I asked, why does it matter whether state information is on a stack or
>in a heap -- either you need the state information, in which case it
>doesn't matter where you store it, or you don't need it, in which case
>it certainly doesn't matter where you don't store it.  You were proposing
>parallelism as an alternative to composition of functions.  And I still
>don't see why parallelism requires less storage than composition of
>functions.
>

One reason for your confusion is that I probably shouldn't have used the
word "procedure calls" above. Maybe repeatedly excuting a block of
instructions might have been a better way to say it. They are not each
executing a procedure that in turn calls any other procedures.

The stack vs. heap issue isn't the main point but let me try to clarify it.
A stack is typically implemented as a block of memory. If the stack grows
too deep, then either a larger block needs to be allocated and the
information needs to be copied over or the another block of memory needs to
be allocated and linked into the original stack. If the heap is used (either
as in ToonTalk or as alternative way of implementing a stack), then there is
nothing corresponding to the unused portion of the block of memory allocated
for a stack. When the number of processes or threads is in the thousands or
hundreds of thousands this can be an important issue. If you expect typical
programs to have tens or hundreds of threads then a stack is a more
efficient data structure than using the heap. My point is that all
sequential languages with threads that I'm aware of are implemented with
stacks. Hence a low limit on the number of processes that are practical.

On the main point, let's consider a program like this. (Excuse me if I make
any syntax mistakes, it has been a very long time since I've written a Logo
program.)

to a
b
c
end

to b
d
e
end

to d
some code that causes this process to suspend
end

Then when d suspends the stack of a -> b -> d needs to be kept until d
finishes.

The equivalent situation in ToonTalk is that b and c are spawned. b causes d
and e to be spawned. d suspends but there is no stack to be saved.

>
>Data that belongs to an object shouldn't be a problem; the object is
>in charge of that data, and it ensures the atomicity of requests to
>use the data, which it can do because it exports the methods to access
>the data.  It's data not belonging to an object that we have to worry
about.

This seems very close to what Java does. A method can be declared
"synchronized" so it is atomic. This can easily lead to deadlocks. I don't
know how frequently it will if kids are programming in such a language.

Best,

-ken kahn (www.toontalk.com)


---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.