Re: scm_wrong_num_args

[Dirk Herrmann]

On 25 Mar 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > 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.
> 
> Yes, but that's a bigger issue than just scm_wrong_num_args, I'd say.

True :-)

> You need to sue the C debugger to debug C code, and it would be nice
> to integrate it with the Scheme debugger.  (That is, GDB should know
> how to debug Scheme code by hooking into the Scheme debugger that runs
> in the Guile process.)

Maybe it can be solved that way.  However, my comment above was given as
a reply to your statement

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

and this is IMO a questionable thing, since the evaluator is basically
only _one_ of many places where a function may be called.  If we have more
than one evaluator (say, bytecode evaluator, jit-compiled code evaluator,
...) and in addition user code which can also call libguile functions, it
can be very well of interest, _where_ the argument checking was actually
performed.  Although, I have to agree with you, that for most of the cases
you would assume that the evaluator itself is bug-free and you would like
to have these stack frames skipped.  Hmmm.

The whole question only comes up, because we pass the 'where' information
explicitly to the error reporting functions.  If, instead, the information
was derived from the mixed C/scheme stack, we could avoid this problem
completely:  When analyzing the stack, we would define some functions on
the C stack, which actually represent scheme level stack frames.  The
evaluator would be such a function, but other functions (like different
evaluators) could be as well.  It could be made into a user configurable
option how a backtrace should be shown, and which functions are considered
source of potential errors:  Scheme level stack frames only or
alternatively both C and scheme level stack frames with and without the
evaluator stack frames themselves.

Best regards,
Dirk Herrmann