[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: <srfi-77@xxxxxxxxxxxxxxxxx>*Subject*: Re: Error objects in general*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Sun, 30 Oct 2005 08:03:41 -0500*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF8A2918.BF49%schlie@xxxxxxxxxxx>*Thread-index*: AcXdTuk5J/+8nUlCEdqjqAADk1ictAAA3Bfm*Thread-topic*: Error objects in general*User-agent*: Microsoft-Entourage/11.2.1.051004

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 <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 >

**Follow-Ups**:**Re: Error objects in general***From:*John.Cowan

**Re: Error objects in general***From:*Alan Watson

**References**:**Re: Error objects in general***From:*Paul Schlie

- Prev by Date:
**Re: Error objects in general** - Next by Date:
**Re: Error objects in general** - Previous by thread:
**Re: Error objects in general** - Next by thread:
**Re: Error objects in general** - Index(es):