This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
> 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 >