Karim BELABAS on Fri, 22 Dec 2000 00:55:37 +0100 (MET)

 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,

> 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
--