NaN's Paul Schlie (29 Oct 2005 15:50 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 16:39 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 18:22 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 19:14 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 22:49 UTC)
Error objects in general bear (29 Oct 2005 19:46 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (29 Oct 2005 20:22 UTC)
Re: Error objects in general bear (30 Oct 2005 05:57 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (30 Oct 2005 14:17 UTC)
Re: Error objects in general Alan Watson (29 Oct 2005 21:26 UTC)
Re: Error objects in general bear (30 Oct 2005 05:40 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 05:45 UTC)
Re: Error objects in general bear (30 Oct 2005 06:08 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 16:49 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 05:54 UTC)
Re: Error objects in general bear (30 Oct 2005 06:07 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 06:46 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 12:39 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 13:04 UTC)
Re: Error objects in general John.Cowan (30 Oct 2005 16:30 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 20:29 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 13:17 UTC)

Re: Error objects in general Paul Schlie 30 Oct 2005 13:03 UTC

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
>