[Developers] If clauses in schedule

Erik Schnetter schnetter at cct.lsu.edu
Tue Apr 8 10:20:56 CDT 2008


On Apr 7, 2008, at 17:10:16, Frank Loeffler wrote:
> On Mon, Apr 07, 2008 at 04:55:13PM -0500, Erik Schnetter wrote:
>> In principle nothing.  One would need to come up with a good  
>> syntax, ensure
>> that the translation happens correctly, and then implement this.   
>> Would
>> this feature be important to you?
>
> I understood that some form of this translation is already implemented
> for the while syntax. I assumed it would be easy to do the same for  
> the
> if statement as well.
> It is not particularly interesting for me, but I feel that introducing
> two different if statements could cause lots of confusion in the  
> future.
> Thus I thought instead of introducing a second 'if' statement we could
> extend the current one such that it fulfilles the request. I could not
> imagine lots of cases where the old behaviour would be changed by that
> except by mistake anyway. And if there are really a few of those  
> cases,
> it might be worth adjusting them if we could avoid two different if
> statements in the future.


The two cases are actually quite different.  If you evaluate an if  
statement before constructing a schedule, then you can have  
descriptions like:

if (forward) {
   schedule A before B
} else {
   schedule B before A
}

This is not possible with if clauses evaluated at run time, since  
these only switch on and off parts of a schedule.  In particular, the  
conditions "A before B" and "B before A" are contradictory.  By  
evaluating the if statement before actually constructing the schedule,  
this inconsistency is avoided.

The new if clauses do not affect the order in which scheduled items  
are executed.  The schedule is constant in time, but certain elements  
are skipped depending on certain conditions.  A schedule description

   schedule A if condX

becomes internally at run time something like

   if condX execute A

similar to the existing

   while condY execute B

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20080408/9145c999/attachment-0001.bin 


More information about the Developers mailing list