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.
bear <bear@xxxxxxxxx> 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
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/