!!!User Guide
We discussed a couple of points on the user guide. 
Our consensus for now is to add items to the user guide methodology as we discover them to be useful, but not to worry too much about the structuring for the next few weeks.

We also talked about time and fairness in the implementation. 
There seems to be a fundamental decision here between, roughly speaking, "fairness" and "timeliness". 
We want one simple rule to govern this distinction, so that we can decide which option is more appropriate (or even which option is appropriate under which circumstances). 
David will work on this for the next meeting. 

!!!Val-to-sequential optimization 
We discussed a methodology issue in variable binding.

Under what circumstances do we use: val x = e f  versus: e >x> f We discussed the transformation from the first to the second as an optimization; since the first uses pruning and thus must create a groupcell, which is less efficient, whereas the second just pushes a binding onto the stack. The two are definitely not semantically equivalent in general; however, if e publishes exactly one value and then completes, they are semantically equivalent in the particular case where the expression is evaluated cooperatively (i.e., it is not possible to evaluate e and f in parallel, or it is not semantically detectable whether they are evaluated concurrently or serially). Intuitively, e should take zero time. Frequently e is just a site call. We'll need to come up with some way to annotate sites so that they are known to have this property. We could characterize it as an algebraic law, and have the compile-time representation of sites include metadata that lists the algebraic laws that the site obeys. We could also give names to frequently-occurring laws and just label the site as following those named laws. The particular property of interest in this case would naturally be: [Mirror Property] f <x< M() = M() >x> f This is a difficult property to prove; it requires ensuring that executing M will never affect the concurrent execution of f and vice versa. 

!!!Things We Don't Have Time To Do 
Could we write a concurrent garbage collector in Orc? We don't have time right now.
 Could we write an interactive loop (REPL) for Orc? Adrian and David have previously discussed on this. But we don't have time right now. 

!!! Class Projects & Graphics 
We discussed possible class projects for Computation Orchestration next semester. Many of the project ideas didn't seem to really make good use of Orc in particular, in the sense that the orchestration in question was very simple and most of the work would be in writing the appropriate sites. One idea that did seem appealing, however, was to make graphical applications that responded to activity within an orchestration. This arose in two different contexts. Jay would like to see visualizations that reveal the activity going on in the orchestration, and would be treated as a superposed observer of the Orc program. David suggested that graphical objects could respond to messages sent by an Orc program, so that the orchestration could control the behavior, motion, properties, etc. of the objects directly. While such a graphical library would be a very useful tool for students to build their own projects, the library itself would take some work to complete.