[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error parameters

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.