27 Temporal Contracts: Explicit Contract Monitors

(require unstable/temp-c)

The contract system implies the presence of a "monitoring system" that ensures that contracts are not violated. The racket/contract system compiles this monitoring system into checks on values that cross a contracted boundary. This module provides a facility to pass contract boundary crossing information to an explicit monitor for approval. This monitor may, for example, use state to enforce temporal constraints, such as a resource is locked before it is accessed.

27.1 Warning! Experimental!

This library is truly experimental and the interface is likely to drastically change as we get more experience making use of temporal contracts. In particular, the library comes with no advice about designing temporal contracts, which are much more subtle than standard contracts. This subtlety is compounded because, while temporal contract violations have accurate blame information, we cannot yet connect violations to sub-pieces of the temporal formula.

For example, applying f to "three" when it is contracted to only accept numbers will error by blaming the caller and providing the explanation "expected a <number?>, received: "three"". In contrast, applying g to "even" and then to "odd" when g is contracted to accept strings on every odd invocation, but numbers on every even invocation, will error by blaming the second (odd) call, but will not provide any explanation except "the monitor disallowed the call with arguments: "odd"". Translating non-acceptance of an event trace by an automata into a palatable user explanation is an open problem.

27.2 Monitors

(require unstable/temp-c/monitor)

Whenever a value v is projected by the result of monitor/c, monitor-allows? must approve a (monitor:proj label proj-label v) structure, where proj-label is a unique symbol for this projection.

If monitor-allows? approves and the value is not a function, then the value is returned.

If the value is a function, then a projection is returned, whenever it is called, monitor-allows? must approve a (monitor:call label proj-label v app-label kws kw-args args) structure, where app-label is a unique symbol for this application and kws, kw-args, args are the arguments passed to the function.

Whenever it returns, monitor-allows? must approve a (monitor:return label proj-label v app-label kws kw-args args rets) structure, where ret are the return values of the application.

The unique projection label allows explicitly monitored contracts to be useful when used in a first-class way at different boundaries.

The unique application label allows explicitly monitored contracts to pair calls and returns when functions return multiple times or never through the use of continuations.

27.3 Domain Specific Language

(require unstable/temp-c/dsl)

Constructing explicit monitors using only monitor/c can be a bit onerous. This module provides some helpful tools for making the definition easier. It provides everything from unstable/temp-c/monitor, as well as all bindings from unstable/automata/re and unstable/automata/re-ext. The latter provide a DSL for writing "dependent" regular expression machines over arbitrary racket/match patterns.

First, a few match patterns are available to avoid specify all the details of monitored events (since most of the time the detailed options are unnecessary.)