Node:Symbol Data, Next:Symbol Keys, Up:Symbols
Numbers and symbols are similar to the extent that they both lend
themselves to eq?
comparison. But symbols are more descriptive
than numbers, because a symbol's name can be used directly to describe
the concept for which that symbol stands.
For example, imagine that you need to represent some colours in a
computer program. Using numbers, you would have to choose arbitrarily
some mapping between numbers and colours, and then take care to use that
mapping consistently:
;; 1=red, 2=green, 3=purple (if (eq? (colour-of car) 1) ...)
You can make the mapping more explicit and the code more readable by
defining constants:
(define red 1) (define green 2) (define purple 3) (if (eq? (colour-of car) red) ...)
But the simplest and clearest approach is not to use numbers at all, but
symbols whose names specify the colours that they refer to:
(if (eq? (colour-of car) 'red) ...)
The descriptive advantages of symbols over numbers increase as the set of concepts that you want to describe grows. Suppose that a car object can have other properties as well, such as whether it has or uses:
Then a car's combined property set could be naturally represented and
manipulated as a list of symbols:
(properties-of car1) => (red manual unleaded power-steering) (if (memq 'power-steering (properties-of car1)) (display "Unfit people can drive this car.\n") (display "You'll need strong arms to drive this car!\n")) -| Unfit people can drive this car.
Remember, the fundamental property of symbols that we are relying on
here is that an occurrence of 'red
in one part of a program is an
indistinguishable symbol from an occurrence of 'red
in
another part of a program; this means that symbols can usefully be
compared using eq?
. At the same time, symbols have naturally
descriptive names. This combination of efficiency and descriptive power
makes them ideal for use as discrete data.