Re: scm_wrong_num_args

[Dirk Herrmann]

On 25 Mar 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > Would it be allright to call this function scm_error_num_args_subr?
> 
> What about scm_error_wrong_num_args_subr?

IMO, "error" already indicates that there is something wrong.  I took the
freedom (some days ago) to apply the suggested patch, using the name
scm_error_num_args_subr.

> > I feel that (in an arbitrary long term) it would be nice to have
> > guile's error reporting functions named scm_error_*.  Do people
> > agree with me?
> 
> Consistency is always a good thing.  I feel the whole error reporting
> machinery needs to be checked for consistency, and before starting to
> change the names only, we should probably first see whether there is
> more to clean up.

One aspect is (as you have suggested) to make the error reporting
functions create continuations to allow to continue the execution after an
error has occured.  This idea can be extended, for example to use the
continuation to extract backtrace information (as a replacement or in
addition to the current explicit stack creation mechanism).  This would
allow to show a mixture of C level and scheme level stack frames.

Another aspect is the error reporting itself.  Some time ago, Mikael has
complained about the misleading error messages that are issued by some of
the SCM_VALIDATE_* macros.  (See his message "Problem with current
validate macros" from August, 13th 2000).  To clean this up, the
SCM_VALIDATE_* macros should be placed in those files, where the  
corresponding types are defined.  There, they should not be created by
SCM_MAKE_VALIDATE, but instead explicitly implemented, which allows to
give better error messages.

Moreover, we should, IMO, provide a more fine grained set of error
reporting functions, which can be used to give more information to the
user, like "Wrong argument type in position 14 (expected proper list, got
circular list):  (1 . #0#)".  Instead of one scm_error_arg_type function,
we could also provide scm_error_arg_type_xpct and
scm_error_arg_type_xpct_got, just to give an example.

With respect to the SCM_VALIDATE_* macros, I'd like a lot of these macros
be removed, namely those which try to do a lot of things in one go, like,
for example, macros like:  SCM_VALIDATE_INUM_MIN_DEF_COPY.  Another
example, which can even lead silently to broken code is
SCM_VALIDATE_LIST_COPYLEN.  It takes three parameters, one of them is the
name of a variable which will hold the length of the list.  One would
assume that you could use an unsigned integer variable or a variable of
scm_sizet to hold the length.  But this would lead to broken code, since
the macro internally assigns the result of scm_ilength to the given
variable :-(

Maybe you have noticed that I have already started with some cleaning
up.  I have for example removed all uses of scm_wta and deprecated this
function.  If you look at the implementation of scm_wta, you will know
why :-)  In any case, I think that we will probably even after all
cleanups end with some error reporting functions like scm_error_num_args
or scm_error_range, even if their implementation differs from today's.
Thus my suggestion to name these functions consistently scm_error_*

Best regards,
Dirk Herrmann