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

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

Brian Harvey wrote
>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.
>

I agree that procedural languages should do tail recursion optimization. But
I was trying to make another point. ToonTalk could be implemented as a
un-ordered collection of process records. A process record is like a stack
frame - it contains a pointer to the code (robots in ToonTalk) and an
argument vector (a box in ToonTalk). To be fairer to conventional languages,
while ToonTalk has very cheap processes, ordinary procedure calls are more
costly since they use the heap rather than a stack. But the fact that stacks
are not used is why process spawning, suspension, and termination are very
cheap operations in ToonTalk.

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

I agree that in programs without side-effects as in functional programming
all my objections and concerns about synchronization disappear. And I agree
some nice programs can be written in a pure functional style, e.g. your
sentence generator. But (and this is my main point here) there are too many
programs that cannot be written as pure functions. The bank account example
I gave earlier is one. Or a score keeper in a game. Or most simulations,
animations, games, etc. Even programs that do I/O are hard to fit into the
pure functional framework.

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

I would rather say I provide a programming technique or pattern of ToonTalk
usage that corresponds exactly to function calling. And I admit it is a bit
more complicated when all you want to do is function calling. But I claim
you want something more general than function calling. Suppose you want to
return 2 items? In ToonTalk you just put 2 birds in the box and as the
values are computed they are given to the birds and their corresponding
nests get filled. Suppose you don't want a single value but a stream of
answers. Maybe even an infinite stream (e.g. the Sieve of Erathosthenes
prime number generator). Suppose you want to create a network of cooperating
agents. And why should one try to force message passing between objects to
fit into the framework of function calling?

We may be losing all but the serious programmers and computer scientists on
this list, but I think this is a good thread. I'm learning how to be clearer
about what I'm doing.

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.