Re: Interface definition for PARI/GP

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

On Wed, Jul 03, 2002 at 07:00:49AM -0400, Ilya Zakharevich wrote:
> On Tue, Jul 02, 2002 at 10:45:05PM +0200, Bill Allombert wrote:
> > > Again, I do not follow.  Only init.c needs to be changed.  (Supposing
> > > that what you want is changing PARI function to reference a different
> > > C function - with possibly different signature.)  Do you mean help
> > > strings again?
> 
> > Yes! If you forget to add an help string, all the online help is shifted! Also
> > there is the section number stuff.
> 
> What about a section number?  How you proposal helps with a section
> number bookkeeping?  Do yo want to keep different sections in
> different mail-format files?

Not decided yet, but it was the original proposal. Karim have proposed to
use a directory by section and one file by function instead, including
the extended help.

> > > Such moving may break the "table sanity check" features of the latest
> > > versions of Math::Pari.  Please announce such moving...
> > Would it be OK src/language/init.c contains *only* the functions_basic array ?
> > It would be difficult to keep src/language/init.c in CVS and updating it 
> > automatically by a script, so we need to put the table in its own file.
> 
> This is fine, especially if you send patches to Math::PariBuild too.  ;-)

I will. Since all support scripts will be in perl, this should not be too
difficult.

> > One benefit of the new system, once you update your program to use it 
> > directly, is that you do not depend of the source filenames, which is not
> > considered a part of the interface.
> 
> > [ We can shuffle all PARI 2.1 source files
> > and still claim be fully PARI 2.1 compatible.] On the other hand, this
> > new system will be part of the interface.
> 
> How?  You probably omit something like "the tables are installed with
> Pari in a well-defined location"?  Or are they compiled-in, and there
> is an interface to query them?

We plan to install them in $share_prefix/pari/ as part of the development
files. (This means they will go in the pari-devel rpm and libpari-dev deb
packages.)

> > > > Type: gen
> > > 
> > > Is this to replace v and l tokens?
> > 
> > Not decided yet.
> 
> Then what does it *mean*?

Either Prototype: hold the full standard protoype, either the prototype without
the {v,l} token, either a new format and then it is not clear if the Type field
is needed.  Either way, the real prototype put in function_basic files will be
the full standard prototype as it is now.

The initial justification to add this field is for GP2C.  The current GP2C
description format cannot represents all prototypes, so sometime protoype are
handled the usual way. In this case, the Type: field allows to specify a more
specific type than gen.
For example, if we know the function return always a vector we can say Type: vec.

I am not settled on this issue. 
Do you prefer for the initial implementation:
1)Keeping the good ol'prototypes
2)Implement a new system.

If 2) what feature do you like to have ?

Bill