| Karim BELABAS on Fri, 22 Dec 2000 00:55:37 +0100 (MET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: finite field |
[Bill:]
> The way function definition are defined in the GP grammar are *bad*
> I spend hours to explain my Yacc parser how to handle that.
>
> This syntax is context-dependent and use "\n" as a terminator...
it's even worse than that actually (examples below).
> If you start like this
>
> f(x)=g(a)=sin(a);<code>
>
> There is no way to add code to f after the definition of g...
> You must use something like
>
> f(x)=if(1,g(a)=a+x);g(3)
Not necessarily, I myself use
f(x) = (g(a)=sin(a));<more code for f>
all the time, mostly to emulate pointer to functions, and alternate between
different sets of routines. In fact, I use the marginally cleaner approach
switch(flag) = {
if (flag,
(f1() = ...); \\ or alias(f1, other_routine1), if I need efficiency
(f2() = ...);
,
(f1() = ...); \\ or alias(f1, other_routine2)
(f2() = ...);
)
}
> Beside f and g have separated variable scope :
> ? f(5)
> %3 = 8
> ? g(0)
> %4 = x
> ?
Indeed. I would expect it to work that way. How would you react if
a = 1
f(x) = x + a
defined f(x) as x + 1 ? It's the same situation, unnested to global scope.
> I don't if there is valuable use of nested definition,
^ know ?
There definitely is.
> I thing that nested definition should at least trigger a warning,
your compiler can do that.
> and even perhaps be forbidden.
No. Because, as you point it,
> On the opposite, add the possibility to affect function to variable
Cheers,
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://www.parigp-home.de/