Defining Data by Behavior and Advanced Applications

Key Insight

The definition of 'data' is not tied to a specific physical representation but rather to the behavior of its constructors and selectors, which must satisfy predefined conditions. For example, for rational numbers, the contract dictates that if 'x' is constructed as '(make-rat n d)', then '(/ (numer x) (denom x))' must be equivalent to '(/ n d)' for any integer 'n' and non-zero integer 'd'. Similarly, for pairs, if 'z' is '(cons x y)', then '(car z)' must yield 'x' and '(cdr z)' must yield 'y'. This emphasis on behavioral contract allows for diverse underlying implementations.

A striking demonstration of this principle is the procedural representation of pairs, where 'cons', 'car', and 'cdr' are implemented entirely using procedures, without any explicit data structures. For instance, '(define (cons x y) (lambda (m) (if (= m 0) x y)))' defines 'cons' to return a procedure. Then, '(car z)' is simply '(z 0)' and '(cdr z)' is '(z 1)'. This implementation, while unconventional, fully satisfies the pair contract, proving that data is defined by its operational interface. This 'message passing' programming style fundamentally blurs the distinction between what is considered 'procedure' and 'data'.

An advanced application of data abstraction is 'interval arithmetic', which manages inexact quantities with known precision. An 'interval' object represents a range of possible values, defined by a lower and an upper bound. For example, a '6.8 ohms with 10% tolerance' resistor is represented as an interval from 6.12 to 7.48 ohms. Operations like 'add-interval' and 'mul-interval' combine intervals to produce new intervals representing the range of the result. Different internal representations, such as 'center and width' or 'center and percentage tolerance' (e.g., 3.5 ± 0.15), can be seamlessly supported. However, even algebraically equivalent formulas for calculations like parallel resistors (e.g., '(r1 * r2) / (r1 + r2)' vs. '1 / (1/r1 + 1/r2)') can yield different interval results, highlighting that the formulation of an expression can significantly impact the tightness of the computed error bounds.