Re: Revision of SRFI 70 available

[bear <bear@xxxxxxxxx>]

This draft effectively eliminates certain properties of
inexactness vs. exactness, and in doing so it creates a
type distinction where none was before.

In the dialect spec'd by R5RS, there was never any situation
where an inexact number was required and an exact one would
not do; thus it was entirely correct for implementations to
return exact numbers whenever the opportunity presented
itself.  An implementation with exact roots in its numeric
system, for example, could return an exact square root of
two, or multiply two such numbers to get an exact two, or
multiply an inexact whatever by an exact zero to get an exact
zero, or subtract a boxed inexact number from itself to get
an exact zero, or whatever. Exactness, where available, was
an unequivocal good.

Compliance with this SRFI requires that implementations
do *NOT* extend exact numerics in any way; rather than
pretending to revise the standard itself, it should simply
point out that the standard permits such extension but
also allows compliance with the present SRFI, which
forbids it.

This is an example of what I meant when I had misgivings
about SRFI-75 (a SRFI about R6RS) being discussed in this
forum (which is NOT about RnRS); it confuses the two
processes to an intolerable degree, and leads the authors
of SRFI's to believe, erroneously, that they have the
authority to revise the standard.

But, process quibbles aside, this reveals a deeper
issue.

This draft intends to constrain implementations from
opportunistically providing exact results or seeking
to provide exact results where other implementations
or representations cannot.  This amounts to treating
inexactness in some circumstances as a *desirable*
property of numbers.  I strongly suspect that if
inexactness has become a desirable property, then it
is most likely because of one or more design mistakes.

This is like deriving a known-false result in mathematics;
it indicates that at least one of the steps along the
way was wrong, and subsequent steps, including the
present SRFI in dealing with inexactness, therefore
invalid (in proceeding, perhaps correctly, from
erroneous premises).  I believe that it indicates that
one or more of the uniform-numeric-vector SRFI's is
in conflict with Scheme's basic design principles
(the preference for exact calculation where possible)
and in need of redesign.

				Bear