This page is part of the web mail archives of SRFI 23 from before July 7th, 2015. The new archives for SRFI 23 contain all messages, not just those from before July 7th, 2015.
> I was wondering if it is admissible for the "error" procedure > to be defined using the "raise" primitive of SRFI 21: > > (define (error msg . args) > (raise (make-error-exception msg args))) > > where "make-error-exception" is implementation dependent. > > I would like this to be explicitly permitted. Agreed. It will be added in the upcoming revision. Note that this definition accepts more than 1 argument, which is currently not required. But I am leaning towards the proposal of Felix. > So in fact my question is: what does it mean to "signal an error"? It's a term I lifted from R5RS. According to R5RS, it means that "implementations must detect and report the error". "Reporting" an error could, IMHO, involve calling an error handler, otherwise every Scheme with error handling capability would be in violation of the standard. My intention was that the implementation does the same thing as it does when a built-in procedure "signals an error". > I think it can't require printing an error message, because even > this is hard to specify (is the standard output used or standard > error? what if there is no stdout and stderr? can a window > with the error message pop up? on what display? can the printer > be used? etc). What about: "The procedure error will signal the error `msg', as described in R5RS. Whatever happens exactly when an error is signalled is left to the implementation, but a reasonable behaviour might be to display `msg' and either terminate the application (for a batch compiler) or go back to the read-evaluate-print loop (for an interactive implementation). It is also explicitely allowed that the error is intercepted by some implementation-specific error handling mechanism, for example by the `with-exception-handler' procedure in SRFI-21." Stephan