Dave Mason <xxxxxx@sarg.ryerson.ca> writes:

> Sorry I haven't been following the (rather long, detailed) discussion
> here, but I would love to see this proposal in effect.  It's important
> that people be able to express the inexactness of their calculations -
> regardless of the type of the result.

Brilliant. When you apply make-string to an inexact integer, we get a
string with an inexact length. When we use it as a file name, the file
is created inexactly. Then checking whether the file exists returns
an inexact boolean - the file might not really have existed after all.
Trying to open it enters an inexact continuation, which lies between
the success contiunuation and the continuation taken in case of an I/O
error. Displaying contents of the file, even if it's English prose,
taints the terminal with inexactness, such that anybody copying the
text into a Scheme program gets back inexact strings.

Huh? Tracking exactness of anything which doesn't model a continuous
domain is nonsense.

Consider this statement:
   (if (< (sin x) 0.0) (newline))
If it doesn't display an inexact newline, you can't say that
inexactness is truly contagious.

> If I have a test suite that claims that a test passes but in reality
> it is dependent on the actual values of operands of inexact
> operations, I would really want to know that.

In this case just don't use operations which might give inexact
results given exact arguments (R5RS: exp log sin cos tan asin acos
atan sqrt expt make-polar magnitude angle exact->inexact) and don't
feed the program with inexact data nor textual representation of
inexact data.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/