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.
> Is there a particular reason why SRFI-23 specifies "error" > to have a single argument? Actually, there is. > I'm just asking, because many > Scheme implementations accept zero or more optional > arguments (in addition to the message), which are output in > addition to the error message. That is true. However, in some Scheme implementations (e.g. Bigloo), the arguments have a very specific meaning. My reasoning was that `error' is a pretty good name, so almost any implementation will want to use this for its own idea of what error handling is, and this SRFI should conflict with that as little as possible. So therefore the arguments of error are very restricted: not only is only one argument allowed but it has to be a string. The idea is that this allows the SRFI-23 error mechanism to co-exist with some implementation-specific error procedure. An example of this is given in the SRFI for Bigloo. Note that the zero-or-more behaviour can be done on top of this SRFI by doing: (define (my-error . args) (error (apply string-append args))) This doesn't work when args contains arbitrary objects, not strings. I am open for discussion on how problematic this is. Perhaps another name should be chosen that isn't so likely to conflict with already-existing features. > How exactly the stuff is presented > to the user can still be implementation dependent. Of course, but at least the semantics should be (somewhat) fixed. It is not good if one implementation decides the 2nd argument if the line number if another thinks the 3rd one is the line number. Stephan