[Ecls-list] undefined-function function args

[Matthew Mondor]

On Fri, 28 Jun 2013 09:56:57 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at gmail.com> wrote:

> The Slime code has code to trace the lisp interpreter stack and local
> variable definitions (this includes function arguments), but this is stack
> is not used by compiled code at all, unless you set very high debugging
> levels.

I agree with the above;

However I think that despite these debugging stacks, there seems to be
no way to do it for undefined function calls (except of course in
SLIME/SWANK related functions if invoked from the REPL)?

Here is a test:

CL-USER> (defun test ()
           (declare (debug 3))
           (wojowej 1 2 3 4 5))
TEST
CL-USER> (disassemble #'test)

#(TEST WOJOWEJ #<bytecompiled-function TEST> SI:FSET) 
Name:           TEST
   0    NOMORE
   1    PUSH    1
   3    PUSH    2
   5    PUSH    3
   7    PUSH    4
   9    PUSH    5
  11    CALLG   5,WOJOWEJ
  14    EXIT
NIL
CL-USER> (test)

But in the SLIME debugger I'm unable to locate those 1 2 3 4 5 which
were pushed on the stack (and there is no function to try to query the
argument list from, since it's an unexisting function, its frame was
never entered).

That said, I'm not sure if there are other implementations which
provide this either, but I think that the original poster's request was
to access the arguments list of undefined function calls as part of the
condition object because of this.

Of course, if I however call (wojowej 1 2 3 4 5) from the REPL, I can
then see the arguments as part of the form stored in SLIME's own
function variables.

Ilya, I'm not sure if you want this for debugging or to implement lazy
function creation.  If for the latter, I would suggest using a custom
protocol to call those special functions which should be automatically
instanciated.  This would be portable and could be altered for your
needs...  i.e. a funcall-like layer.

If it's for debugging, with a high enough debug level we can see in the
stack trace that TEST was the culprit attempting to call WOJOWEJ.  It
would thus also be possible to modify TEST to add explicit checks or
logging.  Is there a reason why is this not enough for your needs?

Thanks,
-- 
Matt