If you are writing good object oriented code, you are modeling the
problem using concurrency even though the actual processing happens
sequentially, correct?  When you are working on a class, you should be
putting yourself into the shoes of an instance of that class and looking
at the environment from its point of view.  You receive messages and you
do something in response.  You are designing it such that it can receive
those messages (events) in no particular order and respond accordingly
while maintaining internal consistency.  What's sequential about that?
We only use critical sections, semaphores, monitors, transactions and
the like so that we can accomodate actual concurrent processing when our
simulation runs.

Internal to any given method, we happen to know that our statements are
processed sequentially, but not all statements necessarily need to be
executed in sequence.  Only when we do something with a result (i.e.
send a message) do we need to make the involved statements sequential,
and we can manage that automatically in a concurrent system with
futures.  Also, if it is critical that multiple messages sent in a
method be dispatched in order, we can come up with some syntactic
construct to express that.  

Currently, we provide sequential operation with constructs to dispatch
statements asynchronously (using fork).  Would it be that much better to
provide concurrent operation with constructs to dispatch statements
sequentially?  Maybe there are some refinements that we can make to the
current system that would make the syntax for asynchronous messaging and
synchronization less cumbersome.

Here's an example of what I mean (angle brackets indicate an
asynchronous send):

someMethod
  <a doSomethingAsync> doSomethingElse.
  b doSomethingSeq1.
  b doSomethingSeq2.

...which would be roughly equivalent to the following:

someMethod
  | tmp |

  sem := Semaphore new.
  [ tmp := a doSomethingAsync.
    sem signal ] fork.
  sem wait.
  tmp doSomethingElse.
  b doSomethingSeq1.
  b doSomethingSeq2.

- Stephen