Re: Process instantiation puzzle

Drew,

I always thought processes as subroutines  so I cannot see the problem. 
 But I suspect you are up to something very important,  can you please 
explain why did you stumble on this problem?  

--- Massimo



Drew McDermott wrote:

>There's a theory of processes in DAML-S that has a lot of support;
>I'll call it the Majority Position because it seems to be, modulo
>various reservations.
>
>The theory goes like this: processes have inputs and outputs.  Where
>these come from and where they go is not part of the definition of the
>process.  In particular, if a composite process C contains an
>invocation of process P, there's no way to know just by looking at the
>definition of C whether P is to be executed by the same interpreter
>(or "enactor") as the one executing C.
>
>Puzzle: Suppose C sends a message to P two or more times, at least on
>some runs, e.g.:
>
>   C = (seq (P) (if Q then ... else (P)))
>
>I've suppressed the actual dataflow, but assume that C is sending data
>to P and getting some back.  With respect to a run of C in which Q is
>false after C interacts with (P), let P1 be that first interaction,
>and P2 be the second.
>
>What exactly are P1 and P2?  Is each a fresh invocation of the P
>process?  Is there a worldwide P process that everyone communicates
>with (e.g., an atomic clock sitting in Geneva).  Or does the
>invocation P1 create an entity that C talks to when P2 occurs?  How
>are these different possibilities to be indicated?
>
>If P is just a subroutine, the answers are clear.  P1 and P2 are
>independent invocations that create fresh processes each time.  How
>does an espouser of the Majority Position answer?
>
>  
>

Received on Wednesday, 24 September 2003 11:34:44 UTC