The primacy of lists in lisp is due to the fact that lisp is its own
meta language and the vocabulary of that meta language is constructed
inductively from lists, symbols and other constants. Furthermore, the
most general graphs can be constuctured entirely in terms of
bifurcations represented as cons cells; and bifurcations have a
primacy over trifurcations etc. Topping this off by using the logical falsity
constant as the token to mark the end of certain kinds of graphs is
entirely natural definition to use.
The lists themeselves will remain in their primacy as a prefered construct of
efficient assembly language programming, (especially if this means your
assembly language is LISP on a LISPMACHINE). Take note Plummer's multilisp
emulator that he implemented on the 3600: Comments in the code indicating that
using (SETQ *STACK* (CONS ELEMENT *STACK*)) was more efficient than
using the C/FORTRAN/PASCAL style INDEX plus ARRAY, because the GC overhead
was smaller than the expense of the extra instructions and memory references
needed to manipulate the more complicated data structure.
But I am arguing the barn door closed after the cows have left.
The recent slant of revised-revised-report-on-scheme has
indeed cleaned up things to make them more acceptable to the
general community; throwing out all the obvious meta language
machinery and with it much of the preference for lists.
The reason that FALSE == 0 in C is not due to the concern for the domain
of numbers. (Since in C one will often mark the end of character strings
with 0, and represent the NULL pointer as 0 also). FALSE == 0 because
of the instruction sets and memory organizations of the machines
on which C was developed. Similarly in PDP10 Maclisp and CADR Lispmachine
NIL == 0 (as a machine location address).