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

[bh@anarres.CS.Berkeley.EDU (Brian Harvey)]

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>In the recent discussion about Logo and ToonTalk, one of the issues was
>about concurrency. I promised a longer response to the question about
>whether the parallelism supported by MicroWorlds is as good as what ToonTalk
>offers. Here's my 7 paragraph long answer:

This is really helpful!  Now I think I can articulate where we differ.

>The lack of subroutines in ToonTalk makes it much more feasible to have much
>larger number of processes than conventional programming languages. The
>reason for this is that everyone implements subroutine calls using a data
>structure called a stack. Stacks are a very effective way of implementing
>procedural calls, including recursive calls. The problem is that each
>process needs its own stack. This makes processes somewhat costly. I've
>tested ToonTalk with tens of thousands of houses (i.e. processes). In
>contrast, when I used Java, it stopped working when I had just a couple
>hundred processes.

I don't understand this.  If the processes were doing embedded recursion,
so that you really need to keep all the state of all the procedure calls
around, then I don't understand how you're avoiding it.  If your
complaint is that the Java stack grows on tail calls, then the problem
isn't with subroutines, but with inferior language implementations.
Use Berkeley Logo instead!  It does correct tail call elimination.

>Conventional languages have shared state. The same variables, data
>structures, and objects can be accessed from different processes (processes
>that share data are often called threads). Sharing state is necessary in
>these languages in order for threads to work together.

Ah, now I see why you keep (incorrectly) saying "global variables" when
describing the alleged limitations of Logo.  Your concern is not with
the scope of the variables but with the sharing across processes.

But (and this is the main point I want to make here) there is another
way to harness concurrency without running into synchronization errors:
functional programming!  Race conditions are possible only if the
various threads are reassigning values to variables.  But there's no
need ever to do that.  (In Logo terms, you never need to use MAKE.)
When you lump functional programming in with sequential programming,
I think you're not really doing justice to the power of procedure
calling as a control mechanism.

Some computations really lend themselves to the imperative model of
programming you describe.  But what about the classic Logo example
of English sentence generation?  I think this is best described as
a composition of functions.  And even if the arguments to functions
are computed concurrently, there is no synchronization problem.

Now, in a way, you DO provide for function calling, with the birds
and stuff.  But I think that, because you deprecate the idea, your
metaphor makes function calling much more complicated than it
should be.  I still don't see why every function call should HAVE to
be a separate process -- maybe because I don't understand what
you're saying about stack space.  Are you saying that separate processes
ensure no mutation of shared variables?  Couldn't you achieve the same
thing by not allowing robots (procedures, I take it) to mutate things
outside of themselves?



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