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

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

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>In procedural language implementations, when a procedure is called (non-tail
>recursively) a frame or record is pushed onto a stack. Each thread or
>process needs its own stack. When a thread suspends all the memory devoted
>to the stack is tied up until the process resumes and the procedure calls
>unwind.
>
>In ToonTalk and related languages, the only memory that a process needs is
>for 2 pointers: to the program (robots) and to the data (box). There is no
>stack. There is no other state. That is the point I was trying to make.

I still don't see the point.  If you take a computation that is naturally
expressed as ONE PROCESS with 100,000 procedure calls, and instead make it
100,000 processes, each with (in effect) one procedure call, you haven't
saved any storage.  If Logo would have needed 100,000 procedure calls, it's
because there are 100,000 pieces of saved state needed for the computation.
Why does it matter whether those 100,000 frames are on one stack or
divided among 100,000 processes?

If you're saying that you can't have 100,000 processes each doing 100,000
procedure calls, then I agree -- but that's not a fair argument.  Logo
doesn't do that.  No language does that.

Maybe I should put it this way:  Instead of 100,000 stack frames, you have
100,000 bird nests.  (If you're not using birds, then you are doing something
that would be a tail call in Logo, and it's not going to grow the stack.)

>But your argument about why concurrency is harmless in functional languages
>doesn't generalize to the multiple paradigm language you are suggesting. If
>you don't do everything functionally then concurrency is dangerous and
>complex. Unless you do things the way ToonTalk does.

That's why I proposed a compromise:  Allow a process to mutate only its
own private variables.  So as long as you avoid mutation you can have
shared data.


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