diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2018-04-30 23:24:11 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2018-04-30 23:24:11 -0700 |
commit | c56d0c84dfe150f5dfe513be2dd9ce105684404b (patch) | |
tree | da612cda3de22fdf7ff784e45522e4c208ebd6eb /METALICENSE | |
parent | 3c2117d285db9faa357a16ab483b04f7cff540f6 (diff) | |
download | txr-c56d0c84dfe150f5dfe513be2dd9ce105684404b.tar.gz txr-c56d0c84dfe150f5dfe513be2dd9ce105684404b.tar.bz2 txr-c56d0c84dfe150f5dfe513be2dd9ce105684404b.zip |
expander: regression in param list treatment.
Change ca6199a that went into TXR 191 was over-zealous in suppressing
expand_param_rec calls for non-macro argument processing. The recursive
calls are needed in order to detect parameters that are special
variables and add them to pspecials. The upshot is that usage such as
the following broke: (lambda (*stdout*) ...) because expand_param_rec
isn't called on the *stdout* symbol and *stdout* is thus not noted as a
special variable, and thus the expander then neglects to produce
(sys:with-dyn-rebinds (*stdout*) ...) around the body of the lambda.
The new compiler introduced at the same time made this harder
to find. Why? Because the compiler ignores the
sys:with-dyn-rebinds special form; it implements its own
handling for specials in lambda and let! So compiled code is
unaffected by this regression.
* eval.c (expand_opt_params_rec): Call expand_params_rec on the
car of the optional var-init pair, whether or not expanding a macro
style parameter.
(expand_params_rec): Call expand_params_rec recursively on any parameter
that is bindable whether or not in macro mode. The two cases fold
together again, and so here we see that the recent fix d934a3e was also
a regression caused by ca6199a.
Diffstat (limited to 'METALICENSE')
0 files changed, 0 insertions, 0 deletions