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 Marcin 'Qrczak' Kowalczyk 30 Oct 2005 14:16 UTC

bear <xxxxxx@sonic.net> writes:

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

All objects, without exceptions.

> We are talking about signs that insanity of one form or another has
> ALREADY occurred.

NaN is not insane.

> In my opinion, anything that happens with an error object (including
> a NaN) is undefined behavior,

Wrong. IEEE-754 specifies what happens with NaN quite clearly.

The point of standarizing it is that programs know how (exp 1000) will
be handled, so they don't have to stay on their head in order to avoid
performing such calls beforehand, which is extremely hard in general.

> 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 spread randomly. It's spread only through arithmetic
operations until it's checked for.

> It's not clear that we should specify *any* particular response to
> insane code that produces NaNs or other error objects.

Matrix multiplication code is not insane, even if the input matrices
happen to contain very big and very small values (which produce +inf.0
and -inf.0 when multiplied, and then +nan.0 when added).

Please show how do you imagine writing matrix multiplication code
which doesn't invoke undefined behavior. With my design it's easy:
all it has to do is checking whether inputs are numbers.

> But I definitely want to know the difference between an operation
> that produced an error and an operation that just retrieved or read
> one.

First Scheme must be extended with an exception / condition system.
Otherwise plain 'read' has no way to report errors, even if there are
no NaNs anywhere.

Then it's easy: if 'read' returned at all, there was no error.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/