Re: Data-flow redux

Drew,

I thought that we were to add a property "processOf" to the parameter 
that allows us to find the process a parameter is related to.  The 
property will tie parameters and processes together so that there is no 
confusion which parameter of which process to refer to. 

I do not fully understand the last example, but I believe that tags are 
no longer needed if we adopt this property.

--- Massimo


Drew McDermott wrote:

>   [Massimo Paolucci]
>   I have to confess,  I still do not understand the need of tagged 
>   parameters.  Can you please explain?
>
>The tags go on steps, not parameters, but we do need to refer to the
>tags in parameter descriptions in order to avoid ambiguity.
>
>Suppose we have a sequence:
>
>   (Sequence (foo) (foo))
>
>where 'foo' is a process with an input parameter 'x'.  If we refer to
>'x', which do we mean?
>
>Tagging the instances solves the problem:
>
>    (Sequence (foo) (tag step2 (foo))
>        (i(in) => x(in step2)))
>
>Which means, "Transmit the value of input 'i' to the 'x' input of
>'step2'.  ('in' is the notation for "input parameter," since
>\downarrow isn't often available.)
>
>The surface notation allows an abbreviation that conceals the problem:
>
>    (Sequence (foo) (foo x <= i(in)))
>
>In the deep notation, this isn't available, although perhaps it could
>be.  It's conceivable that we could get rid of all uses for 'tag' by
>such devices.  But what about:
>
>    (Sequence (tag s1 (toodle))
>              (y(out s1) => x(in s2))
>	      (toodle)
>              (tag s2 (doo)))
>
>Is there a way to avoid tags in a case like this?
>
>                                             -- Drew
>
>  
>

Received on Sunday, 12 October 2003 20:16:52 UTC