| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The scoping is not behind handled correctly for optional
variables. The init-forms are being evaluated in a scope
in which all the variables are already visible, instead
of sequentially. Thus, for instance, variable rebinding
doesn't work, as in (lambda (: (x x)) ...). When the
argument is missing, x ends up with the value : because
the expression refers to the new x, rather than the
outer x.
* stdlib/compiler.tl (compiler comp-lambda-impl):
Perform the compilation of the init-forms earlier.
Use the same new trick that is used for let*:
the target for the code fragment is a locaton obtained
from get-loc, which is then attached to a variable
afterward. The spec-sub helper is extended with a loc
parameter to help with this case.
* tests/012/lambda.tl: New test case that fails without
this fix.
|
| |
|
|
|
|
| |
* tests/012/lambda.tl: Add the test case which reproduces
the compiler failure that was fixed several
commits ago.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lambda.tl test, when compiled, is only testing the
compiler's implementation of the inlined lambda: code
generated from a lambda expression to which arguments are
statically applied. We augment this to also compile
real lambda functions which are called. Everything passes.
* tests/012/lambda.tl (call-lambda): New function.
(ltest): New macro, specifically geared for testing lambda
expressions. When *compile-test* is true, this generates code
which performs two tests: applying the arguments directly to
the lambda, and evaluating the lambda to a function which is
passed to call-lambda, which will then apply the arguments.
We cannot use apply, because the compiler sees through that
and will inline the lambda anyway.
(mltest): Multi-expression version of ltest. This is a drop-in
replacement for mtest in the rest of the file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug affects optional parameters which either
have no default expression, or one that is nil.
For instance x in (lambda (: (x nil))) or (lambda (: x)).
When such a parameter is given the : symbol as an argument, it
is not being bound, as if it weren't there.
((lambda (: x) x) :) -> ;; error: unbound variable x
This issue is not a regression; it was introduced in the
commit which introduced the colon convention to optionals, as
well as init expressions and presence-indicating variables,
commit 68c084269581f32f0a7b859446ae2efb6c6a26c0 made in
February 2014.
This might be the first instance of an interpreter bug being
found that is not present in the compiler.
* eval.c (bind_args): The idea here was that when the argument
to an optional the colon keyword symbol, and the optional's
initform is nil, we can skip the overhead of calling eval to
get that initform's value. Unfortunately, the skip was
extended over the code which binds the parameter. Only
the eval can be skipped!
* tests/012/lambda.tl: New test cases to cover this.
|
| |
|
|
|
| |
* tests/012/lambda.tl: Add tests where apply list supplies :
values to optional params, which must trigger defaulting.
|
| |
|
|
|
|
|
|
| |
* tests/common.tl (*compile-test*): New variable.
(vtest): Compile cases via compile-toplevel if *compile-test*
is true, catching compile-time exceptions.
* tests/012/lambda.tl: Set *compile-test* true and repeat file.
|
|
|
* tests/012/lambda.tl: New file.
|
