On Sat, 29 Oct 2005, Marcin 'Qrczak' Kowalczyk wrote:

>bear <xxxxxx@sonic.net> 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