7.1 Data-structure Contracts

On flat contracts, the new flat contract is the same as the old except for the name.

The generator argument adds a generator for the flat-named-contract. See contract-generate for more information.

When using this contract as the result portion of a function contract, consider using any instead; using any leads to better memory performance, but it also allows multiple results.

The or/c result tests any value by applying the contracts in order, from left to right, with the exception that it always moves the non-flat contracts (if any) to the end, checking them last. Thus, a contract such as (or/c (not/c real?) positive?) is guaranteed to only invoke the positive? predicate on real numbers.

If all of the arguments are procedures or flat contracts, the result is a flat contract. If only one of the arguments is a higher-order contract, the result is a contract that just checks the flat contracts and, if they don’t pass, applies the higher-order contract.

If all of the arguments are procedures or flat contracts, the result is a flat contract.

The contract produced by and/c tests any value by applying the contracts in order, from left to right.

This is a backwards compatibility contract constructor. If neither #<void> nor #<undefined> are arguments, it simply passes its arguments to or/c.

This is a backwards compatibility constructor; it merely passes its arguments to or/c.

If the flat? argument is #t, then the resulting contract is a flat contract, and the c argument must also be a flat contract. Such flat contracts will be unsound if applied to mutable vectors, as they will not check future operations on the vector.

If the immutable argument is #t and the c argument is a flat contract, the result will be a flat contract. If the c argument is a chaperone contract, then the result will be a chaperone contract.

When a higher-order vectorof contract is applied to a vector, the result is not eq? to the input. The result will be a copy for immutable vectors and a chaperone or impersonator of the input for mutable vectors.

If the flat? argument is #t, then the resulting contract is a flat contract, and the c arguments must also be flat contracts. Such flat contracts will be unsound if applied to mutable vectors, as they will not check future operations on the vector.

If the immutable argument is #t and the c arguments are flat contracts, the result will be a flat contract. If the c arguments are chaperone contracts, then the result will be a chaperone contract.

When a higher-order vector/c contract is applied to a vector, the result is not eq? to the input. The result will be a copy for immutable vectors and a chaperone or impersonator of the input for mutable vectors.

If the flat? argument is #t, then the resulting contract is a flat contract, and the c argument must also be a flat contract. Such flat contracts will be unsound if applied to mutable boxes, as they will not check future operations on the box.

If the immutable argument is #t and the c argument is a flat contract, the result will be a flat contract. If the c argument is a chaperone contract, then the result will be a chaperone contract.

When a higher-order box/c contract is applied to a box, the result is not eq? to the input. The result will be a copy for immutable boxes and either a chaperone or impersonator of the input for mutable boxes.

Contracts for immutable fields must be either flat or chaperone contracts. Contracts for mutable fields may be impersonator contracts. If all fields are immutable and the contract-exprs evaluate to flat contracts, a flat contract is produced. If all the contract-exprs are chaperone contracts, a chaperone contract is produced. Otherwise, an impersonator contract is produced.

If the field-spec lists the names of other fields, then the contract depends on values in those fields, and the contract-expr expression is evaluated each time a selector is applied, building a new contract for the fields based on the values of the dep-field-name fields (the dep-field-name syntax is the same as the field-name syntax). If the field is a dependent field, then it is assumed that the contract is a chaperone, but not always a flat contract (and thus the entire struct/dc contract is not a flat contract). If this is not the case, and the contract is always flat then the field must be annotated with the #:flat, or the field must be annotated with #:chaperone (in which case, it must be a mutable field).

A field-name is either an identifier naming a field in the first case, an identifier naming a selector in the second case indicated by the #:selector keyword, or a field id for a struct that is a parent of struct-id, indicated by the #:parent keyword.

If the #:lazy keyword appears, then the contract on the field is check lazily (only when a selector is applied); #:lazy contracts cannot be put on mutable fields.

If a dependent contract depends on some mutable state, then use the #:depends-on-state keyword argument (if a field’s dependent contract depends on a mutable field, this keyword is automatically inferred). The presence of this keyword means that the contract expression is evaluated each time the corresponding field is accessed (or mutated, if it is a mutable field). Otherwise, the contract expression for a dependent field contract is evaluated when the contract is applied to a value.

Contracts for immutable fields must be either flat or chaperone contracts. Contracts for mutable fields may be impersonator contracts. If all fields are immutable and the contract-exprs evaluate to flat contracts, a flat contract is produced. If all the contract-exprs are chaperone contracts, a chaperone contract is produced. Otherwise, an impersonator contract is produced.

As an example, the function bst/c below returns a contract for binary search trees whose values are all between lo and hi. The lazy annotations ensure that this contract does not change the running time of operations that do not inspect the entire tree.

(struct bt (val left right))

(define (bst/c lo hi)

(or/c #f

(struct/dc bt

[val (between/c lo hi)]

[left (val) #:lazy (bst lo val)]

[right (val) #:lazy (bst val hi)])))

If the flat? argument is #t, then the resulting contract is a flat contract, and the key and val arguments must also be flat contracts. Such flat contracts will be unsound if applied to mutable hash tables, as they will not check future operations on the hash table.

If the immutable argument is #t and the key and val arguments are flat contracts, the result will be a flat contract. If either the domain or the range is a chaperone contract, then the result will be a chaperone contract.

If the key argument is a chaperone contract, then the resulting contract can only be applied to equal?-based hash tables. When a higher-order hash/c contract is applied to a hash table, the result is not eq? to the input. The result will be a copy for immutable hash tables, and either a chaperone or impersonator of the input for mutable hash tables.

Each contract will check the corresponding value passed to an abort-current-continuation and handled by the handler of a call to call-with-continuation-prompt.

If all of the contracts are chaperone contracts, the resulting contract will also be a chaperone contract. Otherwise, the contract is an impersonator contract.

If maybe-call/cc is provided, then the provided contracts are used to check the return values from a continuation captured with call-with-current-continuation.

If the argument contract is a chaperone contract, the resulting contract will also be a chaperone contract. Otherwise, the contract is an impersonator contract.

For example, the contract

(flat-rec-contract sexp

(cons/c sexp sexp)

number?

symbol?)

is a flat contract that checks for (a limited form of) S-expressions. It says that a sexp is either two sexps combined with cons, or a number, or a symbol.

Note that if the contract is applied to a circular value, contract checking will not terminate.

This function is a holdover from before flat contracts could be used directly as predicates. It exists today for backwards compatibilty.

This function is a holdover from before flat contracts could be used directly as predicates. It exists today for backwards compatibility.