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:
> (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.
It has always been true that
var
is the same as
(let ((tmp var)) tmp)
and the same as
(car (cons var '()))
> The behavior I'd most like for error objects in a language would be
> that any routine recieving an error object as an argument, unless
> it has an error-handler specified, immediately returns that error
> object without actually running any of its own code.
Doing this for all procedures is insane too, and incompatible with
fundamental properties of Scheme. It has always been true that after
(define (f x) (g (h x)))
the expression
(f x)
is equivalent to
(g (h x))
and you are breaking this. Note that IEEE NaN does not break this.
> NaNs work mostly this way, except that the abort happens only at the
> level of fundamental operations like + and - rather than through the
> entire language.
That's the point. It's applied only to functions which work on inexact
numbers. It's not applied to functions putting values in data structures
nor I/O. (cons x '()) should *always* return a list.
> If we think that this aspect of NaNs is a good idea, we should
> consider the possibility of including it in ordinary function call
> semantics for user-defined functions as well.
No. If a function wants to return NaN when its arguments are NaN,
it can either do it explicitly, or let it happen automatically if it
only uses other such functions. It makes no sense to apply it to all
procedures by default.
> And finally, if we think it's a good idea for the few fundamental
> math operations where IEEE defines it and not otherwise, we need to
> decide why.
While the sum of two unknown numbers is an unknown number, a list of
two unknown numbers is not an unknown object - it's a list of length
two.
Most languages have no problem with accepting NaN, and they don't try
to extend this into the world of exact objects. Inexact numbers are
special because they are inexact.
> And, for what it's worth, this is a simple, clean, general error-
> handling and error-signalling mechanism that's straightforward to
> implement and simple to specify and prove things about,
None of this. Second-class variable values are insane, and
implementations are not prepared to pass a function argument to the
function in a different way depending on its value. It's insane.
Please don't compare your braindead idea to IEEE NaNs which don't have
these properties - they are passed to functions like other values.
--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/