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

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

"Ken Kahn" <KenKahn@ToonTalk.com> writes:
>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.

If in fact c can't run until it gets a result from b, then instead of a lot
of stack frames you have a lot of waiting spawned threads, which also take
some state.  Or, if all your threads really can run concurrently, you have
saved thread state for context switches.  In the Logo version there are at
most three stack frames; in the TT version there are three thread frames
(c, d, e).

If the execution is truly parallel, then of course that state won't wait
around as long.  But unless you're telling me that a thread has *no* state
information associated with it, I'm afraid I still don't see where the
saving of memory comes in.

Now, perhaps you are using a really bad memory management system in which
a large chunk of physical memory has to be allocated for a stack, whether
or not it's used.  But that isn't the fault of stacks, or Logo, or
composition of functions!

And remember, nobody is arguing against concurrency here.  There's no
reason why, if the tasks are independent, a Logo program couldn't say

to a
spawn [b]
c
end

or whatever.  What you are arguing is that the ability to do procedure
calls inevitably leads to storage loss, and I still don't see it.



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