NaN's Paul Schlie (29 Oct 2005 15:50 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 16:39 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 18:22 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 19:14 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 22:49 UTC)
Error objects in general bear (29 Oct 2005 19:46 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (29 Oct 2005 20:22 UTC)
Re: Error objects in general bear (30 Oct 2005 05:57 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (30 Oct 2005 14:17 UTC)
Re: Error objects in general Alan Watson (29 Oct 2005 21:26 UTC)
Re: Error objects in general bear (30 Oct 2005 05:40 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 05:45 UTC)
Re: Error objects in general bear (30 Oct 2005 06:08 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 16:49 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 05:54 UTC)
Re: Error objects in general bear (30 Oct 2005 06:07 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 06:46 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 12:39 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 13:04 UTC)
Re: Error objects in general John.Cowan (30 Oct 2005 16:30 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 20:29 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 13:17 UTC)

Re: Error objects in general bear 30 Oct 2005 05:57 UTC


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