Re: gp_read_str

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

On Thu, Jun 14, 2012 at 10:09:32PM +0200, Dirk Laurie wrote:
> 2012/6/14 Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
> 
> > Maybe it would help if you explained what you really want to do with them?
> 
> I'm trying to embed Pari in a Lua framework.  The typical user program starts
> 
>    x=gen"x"
> 
> The Lua x is now a pointer to the same object as the Pari x.  By providing Lua
> bindings for addition etc, I can build up quite a complicated object from that
> one x.  But it doesn't have a Pari name attached to it, being made from return
> values of Pari functions.  The references are only associated with names in
> the Lua state.
> 
> Now I want to assign that object to something that gp_read_str can see.  The
> reason being that the interface is fairly small and I can't anticipate which
> of the 750-plus functions known to GP might be needed.  So I want to write a
> Lua-callable C function that will take a pointer still referenced to in the Lua
> state and put it somewhere in the namespace know to gp_read_str.  Then anything
> that GP could do, Lua could also do.

I am still not quite clear on what you need.

Maybe you could add an extra function to the GP interpretor that returns
the value of the Lua pointer:
gp_read_str("b=fromlua(\"b\")");

> There is such a namespace, since if I say e.g. gen"p=1+x+x^2" there is now
> an object called "p" known to gp_read_str.  As the libpari manual states.

Yes, this changes the state of the PARI evaluator. 
 
> But if gp_read_str can store something that it computed in a place called
> "p", surely there must be some other routine in the Pari library that can
> store an existing GEN there too?

Not really, this is the state of the PARI evaluator. There is no reason for
anything but the PARI evaluator to change it.
And it was completly changed between 2.3 and 2.5.

There are various subtility in the state of the PARI evaluator (for once there
are two types of variables). So it would be rather dangerous to allow function
to mess with it.

Cheers,
Bill.