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/