Aubrey Jaffer wrote:
> Which bits do you twiddle so you don't spoof the hardware generated
> NaNs?
>
> This is platform dependent, even among IEEE-754 platforms.

Of course. Many aspects of NaNs will be hardware dependent. In
particular, any implementation of context will need information on the
hardware.

> Leaving NaN syntax unspecified does not prevent implementations from
> putting NaNs to any use.

Fine. Why don't we also leave the action of car and cdr on pairs as
unspecified? After all, this does not constrain implementations from
putting pairs to use.

> Many behaviors are left unspecified by R5RS, such as when operations
> on exacts would produce results not representable as exacts; and
> division by zero; and multiplication by exact zero; and syntax for
> EOF.

Yes, but division by an exact zero is UNDEFINED whereas the properties
of a NaN in IEEE arithmetic are well defined.

The thing is, R6RS needs to strike a balance between being sufficiently
specific to be useful and and sufficiently vague to be easy to implement
widely.

> Suppose we read data from a spectrometer, then compute the average of
> each pair of adjacent values and write it out.  None of the values
> should be infinite.  But if somehow a positive infinity and a negative
> infinity were adjacent, the average would be a NaN, which would be
> written out.
>
> The probability of this happening is so remote that writing checks for
> it borders on lunacy.  But stuff does happen -- I would like my
> implementation to choke when reading those NaNs.

Eh? You want to write a program that does not adequately validate its
input and have R6RS do the work for you?

What about a program that reads data from a spectrometer and writes the
average of each pair. The data should all be non-zero, but what happens
if a couple of negative numbers get into the original data stream? Do
you want a version of read that signals an error on negative numbers?

Basically, what is different between NaNs (which sometimes indicate an
error and sometimes indicate missing data) and negative numbers (which
sometimes indicate an error and sometimes indicate valid data)?

Where is the end of this? Are you proposing a series of read procedures:

read-and-signal-error-on-NaN
read-and-signal-error-on-negative-numbers
read-and-signal-error-on-a-null-rather-than-a-pair
read-and-signal-error-on-exact-integers-that-are-not-prime
read-but-not-strings-containing-the-substring-frooble

A clean way to get what you want would be to have two IEEE arithmetic
modules, one which signalled on NaNs (both generated and read) and one
which did not.

Regards,

Alan
--
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México