Overall the question is: if NaN's (aka <indeterminate>/<void> values) are
to be embraced, should their observable effect be more generally defined
throughout the entire language specification? (As otherwise the ambiguities
they represent may either be obscured by subsequent evaluations, or result
in potentially undesirable non-easily foreseen halting errors?)

[or alternatively should all arithmetic operations always return well
specified deterministic numeric values, thereby eliminating the otherwise
necessity for a <indeterminate>/<void>/<nan> value object?]

> From: Paul Schlie <xxxxxx@comcast.net>
>
>> From: Alan Watson <xxxxxx@astrosmo.unam.mx>
>> bear wrote:
>>> It's different because #f is a useful value, not a signal that some
>>> operation failed or was invalid.
>>
>> #f is often used to signal failure. For examples, look no further than
>> string->number and assoc.
>
> - Should there be an observable difference between assoc failing to find
>   a match given operands with well defined values, vs. given operands having
>   un-specified values?
>
> - Should a comparison operation (= 0 X) return #t #f or something else
>   if the value of X is an unspecified NaN value? [as such a value may or may
>   not be 0]?
>
> - what should (list-ref x y) return if y had an un-specified value?
>
> - or more generally, what value should (car #t) or (if #f #f) return?
>
> (Under the premise that calculations should not generally halt execution
>  upon determining an expression's value is un-specified, but rather proceed
>  returning an object having an unspecified value?)
>
>>> In general, operations that are
>>> supposed to retrieve a value can fail, and then what value do they
>>> return?
>>
>> Yup, you've identified one of the oldest problems in interface design.
>>
>> Alan
>> --
>> Dr Alan Watson
>> Centro de Radioastronomía y Astrofísica
>> Universidad Astronómico Nacional de México
>