Re: variable losing its value in 2.0.10

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

> Karim BELABAS writes:
> > > ? a=nextprime(2^129)
> > > 680564733841876926926749214863536422929
> > > ? a=nextprime(a+1);factorint(a*nextprime(a+1))
> > > ^C  ***   user interrupt after 1,053 ms.
> > >  
> > > ? a
> > > a
> 
> > It's lost and it's a feature. A variable's value can be altered in 3
> > different way (there are some other marginal cases which don't matter here):
> > 
> > 1) assignment (a=..., a++, etc.) and the former value is lost, unless it's
> > the initial value (monomial of degree 1).
> > 
> > 2) it can be pushed down/poped out a stack when the frame changes. Ex:
> >   f(x)=...
> >   for(i=1,...)
> > x and i are preserved and their old values are restored when returning from
> > the function/loop.
> > 
> > 3) When recovering from an error (user interrupt is an error). All stacks
> > arising from case 2 above are inspected and values that were pushed down
> > since the last input command (from the GP prompt) are poped out. 

[Ilya:]
> I see no case 2 in the above example.  Thus *what you wrote* about "3"
> is not applicable.

Hmm, I wasn't too clear here, was I? [That's what you get by typing too
quickly a long answer...] What I _should_ have written is:

---
3) When recovering from an error (user interrupt is an error). All the `value
stacks' containing a variable history (such as the ones arising from case 2,
or case 1 with initial value) are inspected: values that were pushed down
since the last input command (from the GP prompt) are poped out, i.e destroyed
and replaced by the most recent of the remaining ones.
---

[ Technical note again: see src/language/init.c:recover()

in fact, the current identifier hashtable is inspected. 

Affected: all user objects but install'ed funcitons. That is: variables
(including temporary loop variables created in sumiter.c, which are of a
special sort since they are not usually stored on the stack), aliases, user
functions, and strings recently seen by the GP parser that were identified as
user function but were not completely processed yet (i.e there was a syntax
error in the function's definition).

Not affected: default and install'ed functions.]

Karim.
--
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (00 33) 1 69 15 57 48
F-91405 Orsay (France)           Fax: (00 33) 1 69 15 60 19
--
PARI/GP Home Page: http://pari.home.ml.org