Re: gp: variables

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

On Tue, 25 Feb 2003, Ilya Zakharevich wrote:
> On Tue, Feb 25, 2003 at 11:50:25AM +0100, Karim BELABAS wrote:
>>> Seems like a bug to me.
>
>> Calling a function as f(x, x = y) is syntactically correct, but should not be
>> used [ this is implicitly what you do, through side effects of subroutines ].
>
>> Basically, it depends on the order in which the arguments are evaluated.
>> The result is undefined [ actually you could get a SEGV here ].
>
> Well, thinking of side-effects of subroutines given as arguments to
> other subroutines is too much to require from users.  Something better
> be changed.

How is a C compiler supposed to react to

  long x = 0;
  long f() { return x = 1; }
  main() { printf("%ld %ld\n", x, f()); }

or worse

  long x = 0, y = 0;
  long f() { y = 1; return x; }
  long g() { x = 1; return y; }
  main() { printf("%ld %ld\n", f(), g()); }

? I fail to see the difference. [ except that the above programs will not
suffer a SEGV, which GP could ]

Global variables are (a necessary) evil. They should be closely monitored by
the users. It would be better if passing variables by reference was available
in PARI, much fewer globals would be needed.

>> There _is_ a bug in PARI here, in that variables may have too short a
>> lifespan: variables values are passed as reference to a cloned "durable"
>> object, not as copies.
>
> "Passed" by who?  The interpreter of '=' and of the function calls?

Yes, in identifier(): basically, evaluating expression "x", where the name
"x" is bound to 'entree *ep' [ i.e ep->name = "x" ], simply returns
ep->value.

>> If this object is affected, so are the values. This
>> is OK in x = y, since the assignment makes a copy of the y-value into x,
> 				       ^
> 				       immediately

Yes.

>> but it definitely is not in function arguments.
>
>> And anyway the possibility of SEGV is annoying...
>>
>> I do not know how to correct this without a major slowdown [ always make full
>> copies, whenever referencing a variable value ]. Adding reference counts
>> wouldn't help, since objects components are modified, without the parent
>> object being able to tell about it.
>
> So the reference count should be on components.

This would be horribly inefficient: each time we refer to a variable, we
would have to recursively update all reference count in all subcomponents
(and subsequently decrease them). It would not be much slower to make a full
copy, then destroy the copy.

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathématiques, Bât. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/