You are looking at historical revision 24207 of this page. It may differ significantly from its current revision.
Design by Contract
Design by Contract - DbC for short - is a metaphor introduced by Bertrand Meyer for its purely object-oriented language Eiffel. The idea consists in strictly separating the concerns of clients and suppliers of code. The supplier of a routine is not obliged to check the validity of its arguments, that's the clients duty. And in fact the supplier mustn't do it to avoid double checks. On the other hand, the supplier has to guarantee correct results of his or her routine, the client can rely on it. It's like a contract between two parties. But like a contract in social life, this software contract must be documented, so that each party knows each-others duties and benefits.
Command-query-separation
Another idea of Meyer's is command-query-separation, where he names a function without side-effect a "query" (it returns part of the state of his objects) and a procedure without returned value acting by side-effect only a "command" (it changes the state of his objects). His suggestion is never to do both in one routine (like the ++ operators in C), write two instead. This is a suggestion only, it can not be enforced.
The contracts module
This egg is an attempt, to bring DbC to Chicken Scheme. A module written in this style - let's call it "example" in this turorial - has to import contracts. Its body should be enclosed in
(doclist '()) ... (define example (doclist->dispatcher (doclist)))
where doclist is a paramter, to generate automatic documentation. This documentation can be accessed by the client in two ways. First by calling (example) without arguments, returning the list of all symbols, exported by the example module, second by calling (example 'foo) returning a representation of foo's contract provided foo is an exported symbol.
Well, this contracts must be supplied, before their representations can be exported. This is done by replacing define and define-syntax in the module body with define-with-contract and define-syntax-with-contract. And of course, these latter macros must contain the actual contracts in some way. <enscript highlight="scheme">
The case of macros
It's easy for syntax-rules macros. After all, matching the macro-code against some patterns is already a domain check! After all, macro transformers have only access to forms, not to runtime values. Hence we have to do only two things, supply a docstring for documentation and export the admissible macro-codes, which can be extracted from the patterns. In sum, checked macros are defined in example's body like this
(define-syntax-with-contract foo
"docstring"
(syntax-rules () (code xpr) ...))
the only difference to define-syntax beind the mandatory docstring - but the textual representations of code ... will be exported by a call to (example 'foo)!
We will not check the macro's range, because that would need another matching process.
The case of procedures
The contracts module supplies a short and a long form of define, where the short form looks
Author
Initial version
Jun 23, 2011