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.
On Sat, 29 Oct 2005, Marcin 'Qrczak' Kowalczyk wrote: >bear <bear@xxxxxxxxx> writes: >> (set! bar plag) ;; the result of referring to it. >> (define gref (cons plag 'foo)) ;; ditto. >> (live-error? plag) ==> #t >> (live-error? bar) ==> #f >> (live-error? (car gref)) ==> #f > Storing in variables second-class objects which can't be transparently > passed as function parameters or stored in other variables would be > insane, would break the fundamental assumption of Scheme that passing > an object around doesn't change its value. Hello?? ERROR OBJECTS, not otherwise-useful values! We are talking about signs that insanity of one form or another has ALREADY occurred. In my opinion, anything that happens with an error object (including a NaN) is undefined behavior, and it's "nice" when the implementor arranges undefined behavior so as to make it easy to track down the error. What I mentioned is a means of localizing it or telling where it occurred (where it is live rather than stale), instead of just randomly spreading it everywhere and making it unclear which operation produced it in the first place. It's not clear that we should specify *any* particular response to insane code that produces NaNs or other error objects. But I definitely want to know the difference between an operation that produced an error and an operation that just retrieved or read one. Bear