Re: scm_wrong_num_args

[Marius Vollmer]

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?

> Actually, the error was detected in the evaluatur, and not in procedure
> make-string.

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.

It is nice that the evaluator provides the innermost backtrace frame
`for free' when displaying the error, but this isn't actually part of
the error message as initiated by the code that detected the error.

> 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.

> 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).


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.