Re: scm_wrong_num_args

[Dirk Herrmann]

On 13 Mar 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > There are two reasons for this:  The first is, that currently the error
> > message is not too helpful:
> > 
> > guile> (make-string)   
> > <unnamed port>:3:1: In procedure make-string in expression (make-string):
> > <unnamed port>:3:1: Wrong number of arguments to #<primitive-procedure 
> > make-string>
> > ABORT: (wrong-number-of-args)
> 
> How would the error message look after your change?

For example:

  guile> (make-string)
  <unnamed port>:3:1: In procedure eval in expression (make-string):
  <unnamed port>:3:1: Wrong number of arguments to #<primitive-procedure 
make-string>
  ABORT: (wrong-number-of-args)

> Implementationally, yes, but conceptionally, I regard the argument
> checking to be part of the called function.  The evaluator should not
> enter the picture explicitely.  The caller of a function is not the
> evaluator but the function `one stack-frame up'.  If you want to find
> the caller, you should look at the backtrace, in my opinion.

Hmmm.  What about C level code that calls libguile functions in a wrong
way?  The backtraces you currently get do only cover scheme level function
calls.  This is nice and easy for people that only use guile from the
scheme level.  It is not so nice for people that extend guile.  For a tool
like guile it is questionable if we say that backtraces are only scheme
backtraces, because the major point of guile is to allow working in a
mixture of scheme and C.

> > Another example can be found in hooks.c in function run-hook, where
> > currently a misc error is thrown if the number of arguments does not
> > match.
> 
> (Why do hooks require a fixed arity anyway?)

:-)

> > Again, a better error was a wrong-num-args error, indicating that
> > the error was detected in run-hook and the wrong number of args was
> > given to the hook object.
> 
> I agree that this should be a wrong-num-args error instead of a
> misc-error.  I don't see why the hook object should enter the error
> message, tho.  run-hook expects a certain number of arguments and it
> will complain if it doesn't get them.  This is the same as cons
> expecting two arguments and complaining in case it doesn't get them.
> That the evaluator checks for the number of arguments is an
> optimization that shouldn't be included in the design of the error
> system.

Well, run-hook does not in general expect a certain number of
arguments.  The number of arguments depends on the hook that is
called.  run-hook only checks if the number of arguments matches the
number that is required by the called function.  However, probably that
check does not need to be performed in run-hook anyway, but it can be
postponed to the call of the hook itself.

> > The second reason is about symmetry, because all other error
> > reporting functions take a const char* indicating the origin of the
> > error.
> 
> What about adding scm_wrong_num_args_subr that takes a string instead
> of a SCM value to indicate the proc that received the wrong number of
> arguments.  This should make it easier for subrs to report this error
> (because they don't have to find the SCM value representing them).

Yes, that would be a good compromise.

> Because we are at it: I don't really like the current error reporting
> system.  I think I would like it when the error object that is thrown
> would contain the continuation of the erroneous expression and the
> debugger would work with this continuation.  Like extracting a
> backtrace from it, inspecting its environment, single stepping it,
> resuming or aborting it, etc.

This sounds like a very good idea.  But, if it was done, we should think
about how we would like to handle a mixture of scheme and C frames on the
stack.  As I said above, generally hiding the C frames does not suit a
tool like guile very well.

Best regards,
Dirk Herrmann