Apparent argument binding issues when attempting to call user defined procedure with multiple arguments

[btwooton]

I attempted to define the following simple lambda procedure in our REPL today:

(define add (lambda (x y) (+ x y)))

The procedure is seemingly successfully parsed in, however when I attempt to call the procedure as follows:

(add 1 2)

I get back the following error:

Error: eval.Variable: variable y is undefined

Not sure what specifically is causing this issue, but it seems as thought the last parameter in the parameter list is not being properly bound to its argument at call time. Notably, the following extended definition:

(define add3 (lambda (x y z) (+ x y z)))

With call:

(add3 1 2 3)

Errors similarly with:

Error: eval.Variable: variable z is undefined

The last parameter is not being bound to its argument successfully. I will attempt to resolve this issue over the week-end when I have time, but thought I would point it out to everyone, because it should be somewhat trivial to resolve.

-Troy

[btwooton]

Famous last words...upon closer inspection, I am having a very difficult time tracking down the origin of this bug. Additionally, variadic lambdas are not working properly either. I attempted to define the following simple variadic lambda:

(define my-list (lambda x x))

This procedure should be able to take in an arbitrary number of arguments and return as its result a list containing all of the arguments that it got. However, an attempt to call the procedure as follows:

(my-list 1 2 3)

Errors with:

Error: DataNode.length: argument is not a list

Something is causing our procedure call/evaluation semantics to fail with both multi-argument lambdas and variadic lambdas. To make matters more confusing, they seem to be failing in different ways. I am going to attempt some exhaustive unit testing at the different links in the evaluation chain to see if I can elicit what is happening here.

[btwooton]

Fixed the issue behind multi-argument lambdas. The issue was in Procedure_impl.h, inside of the call() method. The for loop in which the argument bindings were occurring was looping while i < args_list_root->length(). This was a subtle bug: the fact that we were performing args_list_root = args_list_root->cdr() inside of the body of this same loop was undermining this check, and we failed to loop the final time needed to bind the last argument. The fix was simple: save the length of the arguments list in a variable prior to entering the for loop, and check the value of i against that original length instead of the length of the mutated arguments list.