```Until we write this up, here are a couple of messages from the e-mail thread:

! On 29 Apr 2016, at 16:27, David Kitchin wrote:

As I was listening to Richard Fujimoto's talk, and thinking about how we handle simulation in Orc using Vwait, it occurred to me how we might simplify a long-standing problem with Vwait and its associated machinery. We've known for years that Vwait is really a combinator, since it is not possible to detect quiescence using the other combinators, and it is too pervasive and too specific to Orc to be a site. We've had various discussions within the group about how to make it 'nicer' to work with.

I realized that it's actually quite simple, and I just talked with Arthur to hash out some details:

Introduce a binary combinator 'onidle' (Arthur proposed this name and I like it, though I'm not attached to it). Write "f onidle g". It has one reduction rule:

{{{
f quiescent
f not halted
-------------
f onidle g -> (f | g) onidle g
}}}

We can do the rest of the work in "userland", that is, using the Orc program itself. This solves an enduring problem with Vwait, which is that the event space itself should be programmable (i.e. not just natural numbers), but all of our attempts to do so have required weird machinery that crosses the language boundary. Here, onidle provides a trigger, and then we can do the rest in the triggered expression.

For example, here's Vwait:

[{orc runnable=false

-- event queue
-- Pretend that this is a heap with an advanceBy(i) method to decrement
-- the keys for all heap items by i.
val q = EventQueue()

def Vwait(i) =
Cell() >wake> q.enqueue(i, wake) >> wake.get()

-- How to dequeue and wake the next Vwait call
def Vnext() =
q.get() >(i, wake)> q.advanceBy(i) >> wake.put()

-- Run simulation
f onidle Vnext()
}]

Now, it is very simple to change the representation of the time domain, or any other details about the event handling (including the potential for computations outside of the simulation to interact with and manipulate the event queue).

I'd love to chat about this more if we find we have time over the next day or so.

- Dave

{{{
f halted
---------
f onidle g halted
}}}

! On 30 Apr 2016, at 10:06, David Kitchin wrote:

The rule is intended as an additional transition rule in the operational semantics; it's not an axiom on its own.

We do need some conditions on which sites are quiescent or nonquiescent during their execution, to ensure that the expression f under inspection remains nonquiescent while processing the trigger it receives from the execution of g. In particular the machinery used within Vwait must include some call that becomes nonquiescent before g becomes quiescent. Otherwise we could dequeue and buffer an unbounded number of events simultaneously. Arthur and John and I have been discussing this.

```