Re: Error objects in general

[Paul Schlie <schlie@xxxxxxxxxxx>]

> From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>
> 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
>