Ballot clarifications

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

A couple of things that you asked about in your ballot:

You ask whether, if *IBASE* (or *READ-BASE*) is > 10, some things that
would otherwise be symbols would be read in as numbers.  I think that
the guiding philosophy here should be the one you proposed: *IBASE* is
for reading in data files through the Lisp reader (and maybe for
compatibility packages) and not for code.  In a compatibility package
(for code from Maclisp or @i[Cadropithecus robustus]), the issue does
not arise, since the IBASE in question is octal.  In reading data, the
rule should be that if it can be parsed into a number in the current
*IBASE*, it will be; else it is a symbol.

On the GET-REAL-TIME proposal, I'm afraid I didn't explain this very
well.  GET-UNIVERSAL-TIME is meant to produce a number that can be
decoded to find the current date and time in absolute terms.  This might
take a while to get, so it's useful for finding the current time of day
but not for fine-grained measurement of elapsed time.  GET-INTERNAL-TIME
and GET-REAL-TIME are relative times expressed in "internal-time"
format.  These are for timing various executions but do not give you any
absolute time.  You call one of them twice, subtract, and then divide by
INTERNAL-TIME-UNITS-PER-SECOND to get the elapsed time in seconds.  The
number of units per second is chosen to give a reasonable balance
between clock accuracy and fixnum size on a given implementation: the S1
needs a granularity of picoseconds and the Perq can get by with seconds.
My proposal is simply that sometimes you want elapsed runtime and
sometimes you want elapsed clock-on-the-wall time.  I was going to
propose calling these GET-ELAPSED-RUNTIME and GET-ELAPSED-REALTIME, but
each call to these functions returns only a single point, not an
interval, so that would be misleading also.

-- Scott