I wrote:
> > And I am talking about true concurrency not some approximation. So the
game
> > can have a second paddle that is running on another computer as a way to
get
> > the game to work over a network.
>
>
Lex Spoon responded:

> I would prefer to program this as a list of event handlers.  "When the
> ball gets close, do this".  "When the joystick moves, do this".  If I
> write each of these as a thread, they will probably end up having an
> outer loop which is an event dispatcher!
>
> [ true ] whileTrue: [
> self waitForEvent.
> self nextEvent dispatch ]
>
> By the way, it is very natural in morphic to program your objects as a
> list of event handlers.
>

Event handlers have lots in common with what I'm suggesting. Here are
differences (though I admit I have yet to look at Morphic carefully and plan
to):

1. All communication is asynchronous. This would translate into never using
call/return message sending but instead posting events and have event
handlers.

2. Morphs are tied to graphics - I'm suggesting a general style of computing
that includes graphics but also quick sort and bank accounts.

3. Every object is a "thread" as you suggest. I'm agnostic about whether the
iteration is implicit, iterative as in your example, or tail recursive (as
is the common programming technique in concurrent logic programming).

4. I'm a bit unclear about how you would express "When the ball gets close,
do this".  Does each object periodically check its distance from the ball or
can it register and be notified?

>
> So, while I agree that making things psychologically natural is
> important, in what cases does concurrency really help?  I've seen an
> occasionaly case, but not a lot of them.  And they add headaches when
> you start worrying not only about the *state* of another process, but
> the *position* in its computation that it might be at.  The argument for
> threads often comes from making explicit state implicit in the process's
> stack; however, making this actually makes it hardet to understand
> what's happening if you end up caring.

I agree. Mixing concurrency and shared state causes headaches that we all
want to avoid. My answer is that there is no shared state and no process
state (there is no *position* in a computation to worry about - remember I'm
getting rid of sequential composition). There are just concurrent objects
that send messages asynchronously. E.g. actors. Though I'm arguing for
something a bit more flexible than actors where there can be multiple mail
boxes, where mail boxes are first class, etc.

I wrote:
> > And I am talking about true concurrency not some approximation.
>
And Andreas Raab responded:

> What exactly designates "true" concurrency? Considering that we're still
> talking about sequential execution on some processor it seems hard not
have
> "some approximation".
>

The implementations may be limited to sequential execution on a single
processor but the important thing is the semantics of the programming
language. You don't need to change an actor program, or a concurrent logic
program, or a ToonTalk program to run it on a multi-processor or over the
network.

> Similarly:
> > I'm one of those radicals that prefer programming languages that only
> > support concurrent computations. Sequentiality isn't hard to
> > program in a concurrent language while concurrency can only be
> > simulated in a sequential language.
>
> Wouldn't it be more adequate to say that in a true concurrent language you
> can only _simulate_ sequential execution?! Also, what makes you think that
> it's easier to simulate sequentiality in a concurrent rather than
> concurrency in a sequential language?!

In a concurrent language you aren't simulating sequentiality, you are
programming in a fashion that guarantees it. The most common way to do this
in concurrent logic program is to add two extra arguments to everything (at
least everything that you want to be able to make sequential). One argument
is how you find out if the previous computations have completed and the
other argument is how you inform subsequent computations that you have
completed. It is similar to how concurrency is constrained in data flow
systems.

You can simulate concurrency in a sequential language but it won't help you
when you really want some concurrency - e.g. running on multi-processors or
distributed networks.

Best,

-ken kahn ( www.toontalk.com )