Re: Performing an Iterate

> [Moh.-Reza Tazari]
> considering iterations, I encountered a problem for which I would like 
> to propose a solution. 
> ...
> The issue
> ---------
> 
> Considering the concept of 'Iterate', I believe that it would be wrong 
> to wrap the definition of, say, a 'whileProcess' in a named perform, 
> because each loop should result in a new perform instance.
> 

I don't understand what you're referring to.

> [proposed solution deleted]

> A client encountering a LoopedPerform with ID 'x' must take this as a 
> "virtual" perform holding place for a number of actual performs with the 
> IDs 'x_1', 'x_2', ... and must setup the perform context for each call 
> accordingly.

What I'm not getting is why the case where the body of a loop consists
of a single Perform is so important.

> 
> The consequence
> ---------------
> 
> A standard variable could be introduced representing the perform 
> instance from the previous loop in an iteration.

I'll take a wild guess that you're referring to the problem of
dataflow from one iteration of a loop to the next.  I think the way
this ought to be done is by introducing special loop variables whose
value on iteration i+1 is a function of their values on iteration i.
These variables are called "state variables": 

Presentation ("Surface") Notation:

iterate (state-vars: (---declarations---),
         initialize: (---param-bindings---),
	 update: (---param-bindings---)
while test
{ 
  ---body---
}

param-bindings are those expressions of the form v <= e.  I use the
term "param expression" to refer to the e's on the right-hand side of
a param-binding.

Ground rules: 

The 'update' bindings specify how the values on iteration i+1 are
derived from values on iteration i (and values computed by steps in
the body during iteration i).  In the 'update' field any occurrence of
a loop-state variable in a param expression refers to its value on
iteration i. Similarly, any 'produce' in the body of an Iterate gives
the value of a state variable on the next iteration.  It's illegal to
have the value specified more than once (dynamically, not
syntactically). 

If a loop is tagged:

tag :: iterate () while ...{ ....}

then tag.v refers to the value of state variable v after the last
iteration of the loop.  

Obviously, this general scheme needs to be sweetened with some
syntactic sugar for special cases such as iterating through elements
of a collection, or doing some action for all objects known to satisfy
a given predicate.

The motive behind this design is to make data flow more intelligible
to automated tools.  No complex analysis is required of exactly when
variables get set, or who sees what value when.  At the point where a
parameter gets a value, the notation says exactly where that value
comes from

> P.S.
> ----
> By the way, the following excerpt from 
> http://www.daml.org/services/owl-s/1.1/overview/:
> 
> <owl:Class rdf:ID="Iterate">
>    <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
>    <rdfs:subClassOf>
>      <owl:Restriction>
>        <owl:onProperty rdf:resource="#components"/>
>        <owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
>      </owl:Restriction>
>    </rdfs:subClassOf>
> </owl:Class>
> 
> seems to be erroneous, because in 
> http://www.daml.org/services/owl-s/1.1/Process.owl the domain of 
> 'components' is explicitly restricted to a union of which 'Iterate' is 
> no member (which is reasonable IMHO).
> 

You're right.  In the process model, that bit is missing.  We will
delete it from the overview.

The RDF for my Iterate proposal would treat state-vars, initialize,
and update the way parameter declarations and outputs are handled in
IOPRs.  Here's a template (for the RepeatWhile case):

<RepeatWhile>
    <hasStateVar>
      <owl:StateVariable rdf:ID="VARNAME">
        <process:parameterType rdf:datatype="TYPE"/>
      </owl:StateVariable>
    </hasStateVar>
    <initialize>
       <Binding>
          <toParam rdf:resource="#VARNAME"/>
	  ...
       </Binding>
    </initialize>
    <update>
       <Binding>
	 <toParam .../>
       </Binding>
    </update>
    <whileCondition>
       ...
    </whileCondition>
    <whileProcess>
       ...
    </whileProcess>
</RepeatWhile>    

                                             -- Drew


-- 

                                         -- Drew McDermott
                                            Yale University
                                            Computer Science Department

Received on Tuesday, 10 May 2005 16:47:08 UTC