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/