Concurrency mostly involves the unit of the Process, which is conceptually a manager for a single interpreter. Concurrency may be performed within the context of a single process, using stack / control-flow interaction, or across processes using messaging.
Processes in Slate run in turns, each acting as an interpreter with an event loop. They also act as object pools, being opaque and having a context with various local elements which must be explicitly published to be visible to objects in other Processes.
Coupled with event-loop concurrency is Slate's support of deferred execution, using the % prefix for selectors (for the message-send) or for entire expressions. When a deferral is performed on a message-send, we call it an eventual message-send. If the return value is in a syntactic position where it might be used, the caller may expect an object of type Reference or Promise to be delivered as the answer. These objects are resolvable placeholders, which may also communicate errors in the requested computation.
What's significant is that the use of deferred evaluation means that the relevant expression costs the caller nothing in the immediate execution turn; no matter how expensive side-effecting an expression may be, it will not be executed until at least the next turn in the owning process. Specifically, when a deferred expression is evaluated, it is turned into an event and added to the end of the owner Process' queue. When a process finishes each turn, it executes one event at a time from the other end of the queue. Also, if one deferred expression involves the use of the return value from another deferred expression, the dependency will be enforced so that such events will execute in the data-flow partial order in which they were created.