!Time and Rounds 

Fundamentally, we are looking at a situation where an idealized implementation would be able to fulfill the language semantics, but no actual implementation exists that can do so. So, we need to decide what semantics to try to implement, and discover which ways an implementation will fall short. What are our options? We have, it seems, two options:
Only some things take time; rounds are zero time, time only advances between rounds. Some sites are immediate, meaning they return within the same round, and some are not, meaning that they must wait until the next round. Time only advances in between rounds; rounds themselves take no time.
Everything takes a little time, including recursive calls and any kind of site call or return. There is an argument for prioritizing certain transitions, such as publishing a value, over calls or returns, because otherwise programs may be more difficult to reason about or certain algebraic laws may not hold. But other than that, there are no rounds.

* #1 theoretically preserves some nice properties related to time and is not interruptible by outside events.
* #2 is never unfair.

Adrian: How does option #1 interact with being able to read the current time? 

David: We can make observations of the current time non-immediate; the time can only be read between rounds. 

Adrian: Let's make sure that
{{Rt(1) >> Lt(1) >> Rt(1) >> Lt(1)}}
remains equivalent to 
{{Rt(2) >> Lt(2)}}

Adrian: Maybe we should associate a logical timer with the real timer, so that it correctly obeys logical time axioms too. 

David: It seems that there are two ways in which a program may be unimplementable, one of them relevant to Rtimer and the other to Ltimer. 
Rtimer represents a relationship to the global timeline. We cannot use Rtimer to perfectly synchronize across multiple machines, because the clocks may be skewed. An ideal Rtimer would read an exact global time; an actual Rtimer reads it at some lower granularity, or with some small wobble.
Ltimer represents a logical synchronization mechanism. With an Ltimer we can achieve perfect synchrony, but only across a computation which is scheduled by one entity which obeys that logical timeline; in practice, we can only get a small area out of a wide-area computation under the same schedule. An ideal Ltimer would be able to synchronize any two computations, regardless of how far apart they are; an actual Ltimer may be limited to synchronizing activity within a single cluster, machine, process, or thread.

We also discussed ChucK and how its time semantics relate to ours. Adrian pointed out that Orc's time semantics is more expressive than ChucK's, since we can express the use of 'now' in ChucK using Rtimer in Orc. However, there is one important difference: ChucK explicitly allows different timelines running independently; we do this only with logical timers. 

!Package System

We also discussed our options for packages and modules. The main points of contention were:
* Do packages have goal expressions?
*Can packages have val declarations (internal computations)?
*If packages have vals, can we export those vals and see unbound variables? In other words, can a package initialize and execute concurrently with the program that is using it?
*Should we implement packages at this time? No, because:
*We don't have a clear idea of what packages/modules should do. Do we just want simple namespace restrictions, or do we want a more elaborate import/export dependency mechanism?
*We don't have time at the moment, and it would be a long-running project.
It would interact with other language features that are still unfinished, such as type checking.