Loose type checking in E

[Tyler Close]

At 01:05 AM 10/17/98 -0400, I wrote:
>Well, I am by no means done reading all of the Actor links that you
>recommended; however, I feel that I am ready to state my gripe in Actor
>terminology.
>
>The Actor theory depends on partial orderings of events in order to perform
>real calculations. I can see how your Promise objects will enforce the
>activation ordering; however, I see no mechanism for enforcing the arrival
>ordering.

I think the problem here is that each vat has only one receive queue. To
accommodate the Actor paradigm, each vat will have to be able to maintain
multiple dynamically created queues. When a calculation depends upon an
arrival ordering, the initial event should specify a unique, pre-arranged,
random number to identify the new arrival ordering and specify the integer
range for the number of events in the ordering. Each event in the arrival
ordering will then carry this queue identifier as well as its integer
position in the ordering. The vat will then need to keep each receive queue
sorted based on the integer order position, and service the events in
sequential order, blocking as necessary.

If a vat is blocked on one queue and wishes to service an event on a
different queue, then the vat will have to retain a version of its current
state to be used when it becomes unblocked on the original queue. This
version will then be used for all subsequent events in the original queue.

Once an arrival ordering (queue) has completed the terminal event, the
created version, if any, becomes the master state of the vat.

There is no need to ensure serializability of queue versions, since the
activation ordering is ensured by the Promise objects.

Tyler