Re: special declarations

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

Sam wrote:
> this one should be better:
>
> --- control.d	17 Jan 2005 22:24:12 -0500	1.117
> +++ control.d	19 Jan 2005 15:20:05 -0500
> @@ -457,7 +457,7 @@
>              }
>              /* store special-declared symbol in stack: */
>              pushSTACK(specdecl); /* SPECDECL as "value" */
> -            pushSTACK_symbolwithflags(declsym,wbit(active_bit_o)); /*
> Symbol active */ +            pushSTACK_symbolwithflags(declsym,0); /*
> Symbol inactive */ check_STACK();
>              spec_anz++;
>            }

Yes, this one is part of the solution.

> > Can you add test cases that exhibit the bugs in your patch?
>
> done.

Good. I extended the tests by checking the variable's value after unwind()
and by testing also without SPECIAL declaration.

> >> the remaining 2 bugs are in funcall_iclosure():
> >>
> >> Form: (LET ((X 5)) (PROGV '(X) '(20) ((LAMBDA (&OPTIONAL (X (1+ X)) (Z
> >> (1+ X))) (DECLARE (SPECIAL X)) Z))))
> >> CORRECT: 7
> >> CLISP  : 22
> >>
> >> Form: (LET ((X 5)) (PROGV '(X) '(20) ((LAMBDA (&OPTIONAL (Y (1+ X)) (Z
> >> (1+ X))) (DECLARE (SPECIAL X)) Z))))
> >> CORRECT: 6
> >> CLISP  : 21
> >
> > Uuh, this one is a little more complicated to fix, because it probably
> > requires a modification of get_closure() as well.
>
> yeah...
> I think the order of variables in clos_vars should be reversed: now
> specials come first, actually, the formal arguments should be first.
> (so that they will be bound first).

The order in the frame is normally not relevant; what is relevant is
the moment at which the active_bit gets set.

The order is only relevant for the case when an X is both declared SPECIAL
and bound:    (LET (... (X ...) ...) (DECLARE (SPECIAL X)) ...)
Here X will be twice in the frame: once for the binding, with
dynam_bit and - after the binding is activated - active_bit, and
once for the SPECIAL-declaration, with first 0 and then just active_bit.
Looking at symbol_env_search, we see that it looks only for elements
with active_bit and without dynam_bit. Therefore you can indeed reverse
the order.

Whether you want to actually reverse the order, depends on whether it
simplifies the code. Having at the beginning a loop with puts the variables
into the frame with flags 0 and at the end a loop which adds active_bit
to each element, is not so efficient.

> > Programs and testsuites behave like elements of a vector space and
> > its dual space, respectively.
>
> Actually, the other way around.
> Programs are functions on test cases (not testsuites),
> so test cases are elements of the "base space",
> and programs belong to the "dual space".

You lost me here a bit. I thought the thing that's easiest to define
is a program (e.g. the Turing definition). -> Vector space P.
Then you can make statements / test cases about the program. -> Vector
space P*. A test suite would then be a set of elements of P*.
And a specification like ANSI CL, which describes the set of valid programs,
is an element of P**.

> (i.e., Gelfand's map is not surjective).

Oops, I have no idea whether the theory about vector spaces, the theory
about Banach spaces, and the theory about complex algebras have the same
kinds of theorems regarding P, P*, and P**.

Bruno