Re: special declarations

[Bruno H. <br...@cl...>]

Sam wrote:
> 2 tests fail:
>
> RUN-TEST: finished "tests/bind" (2 errors out of 32 tests)
> 32 ;
> 2
> Form: (LET ((X 5)) (PROGV '(X) '(20) ((LAMBDA (&OPTIONAL (X (1+ X)) (Z (1+ X)))(DECLARE (SPECIAL X)) Z))))
> CORRECT: 7
> CLISP  : 6

Yes, for this test to work, the first (1+ X) has to refer to the lexical
binding and the second (1+ X) has to refer to the global binding. Either,
as you say, the activation of the of X
                 |here
      (X (1+ X)) | (Z (1+ X))

must also the the active_bit in the (X, SPECDECL) pair, or symbol_env_search
must be changed to also look at dynam | active pairs.

For the latter to be consistent with the way it works after an environment
is nested (:= moved into the heap), we need to verify how nest_var works:

  (defvar x 5)
  (setq func
        (let ((x 10)) (declare (special x)) #'(lambda () x)))

func must refer to the special variable x (value 5) although the binding
of x as a special variable has already been undone.

It looks like you also need to read the code of nest_var() in order to
understand how things are meant to work...

> >> I wonder if keeping two separate vectors of special vars and args
> >> and binding the specials only after argument processing right before the
> >> implicit_progn() is a cleaner solution.
> >
> > It would consume more memory - gratuitously.
>
> an interpreted closure is a rare beast, I wouldn't worry about this too much

Huh? An interpreted closure is very frequent when you load a program in
interpreted form.

Bruno