Question about new implimentation of kill

On Tue, 2005-04-05 at 00:56, C Y wrote:
> If I'm understanding this correctly, kill now refuses to kill any
> symbol not defined by the user?

Not quite. When kill is called on a symbol in the maxima package meeting
a certain list of requirements, the symbol is restored to its original
symbol value and property list. The symbols that get passed to kill when
kill(all) is called are the members of the lists enumerated in
$infolists.

Which values get passed to kill can be surprising. Nonethless, the
results of kill should now be much, much less surprising than they were
before.
 
>   In general this is good, but I have a
> specific instance (the proposed post_eval_functions list) where I would
> like kill to reset the value of this variable to an empty list (this
> would, I think, be the "expected" end user behavior.)

Right. I think you want $post_eval_functions to behave more-or-less the
way $rules does when it is handed to kill. $post_eval_functions would
then have to become a member of $infolists and a special case might have
to be added to the kill command. If you look at the code for kill, I am
guessing you will find it much more complex than you thought.

>   Is this
> possible?  Or, less ideal but possibly still workable, is it possible
> to at least expose $post_eval_functions to kill despite its being
> defined at compile time, via some explicit instruction?  Here's what
> I'm seeing now:

I'm not sure what happened in your example because I don't know how you
have implemented post_eval functions. Nonetheless, I wouldn't expect the
kill logic to automatically know what to do with your new variable. That
isn't the way it works.

--Jim