Re: New experimental GP parser release 2.4.1.bill-3

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Wed, Oct 25, 2006 at 06:20:49PM -0700, Ilya Zakharevich wrote:
> > A closure is a perfectly standard GEN object and can be handled
> > in the same way.
> 
> I do not think we want to have closures BEFORE the major problems with
> dynamic variable lookup are well understood.

We already have closures, user functions and loops are using closure
internally. What I propose is a new way to store closure instead of
plain text.

> For the simplest case, consider
> 
>     ? f(x_y_z) = 11
>     ? ?0
> 
>     f     x     x_y_z
> 
> Why did x_y_z jump into existence?  This variable should have no
> visibility outside of f():

We should mark variables which only exist as local specially in the
symbol table (so we do not create 'x_y_z).

>     ? x_y_z(ttt) = 44
>       ***   unused characters: x_y_z(ttt)=44
> 				    ^--------

The plan is to allow x_y_z to exist both as a variable and a function in
the symbol table.

> When one feels that semantic of variables is documented well enough,
> one can ask for semantic of anonymous functions; IMO, not in the other
> order.

The problems you mention are listed in my PARI Workshop slides:
<http://pari/Events/IHP2004/Bill.Allombert/language.ps.gz>

I plan to add a new my() to declare lexicaly scoped variable,
so local() and my() would have the same behaviour as in perl.
Functions parameters should be lexicaly scoped instead of
dynamically since this would allow much faster user function call,
but this would breaks backward compatibility.

But this will only happen once the old parser is replaced by the new
one. One step at a time!

Cheers,
Bill.