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 colors in a computer program. Using numbers, you would have to choose arbitrarily some mapping between numbers and colors, and then take care to use that mapping consistently:
;; 1=red, 2=green, 3=purple
(if (eq? (color-of vehicle) 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? (color-of vehicle) red)
...)
But the simplest and clearest approach is not to use numbers at all, but symbols whose names specify the colors that they refer to:
(if (eq? (color-of vehicle) '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 vehicle1)
⇒
(red manual unleaded power-steering)
(if (memq 'power-steering (properties-of vehicle1))
(display "Unfit people can drive this vehicle.\n")
(display "You'll need strong arms to drive this vehicle!\n"))
-|
Unfit people can drive this vehicle.
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.