Re: Interface definition for PARI/GP

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

On Sun, Jun 30, 2002 at 09:57:54AM -0400, Ilya Zakharevich wrote:
> On Sat, Jun 29, 2002 at 06:57:34PM +0200, Bill Allombert wrote:
> > Currently most of the interface between the library and the language is built-in
> > the file src/language/init.c as the function_basic array.
> > 
> > This scheme has several short-comings:
> > 1) External programs that rely on this interface need to parse this file which
> > is not installed on the system (src/language/init.c, etc). This may cause
> > version mismatch
> 
> What for?!  They can load PARI DLL and get this array in memory...

... On platform where DLL are supported ? Else we are stuck with static linking and 
you need the name of the C function.
> Or do you want to find the *name* (as opposed to the address) of the
> responsible C function?
Yes, exactly! For GP2C at least.
> 
> > 2) Only the information needed by GP is available.
> 
> Hmm???  The full signature is there.  What more do you want?  Help
> strings?  Do not see this in your example...
I removed it for brievety. bnfinit was a poor choice, sorry.
> > 3) To extend the interface, you need to change several files.
> 
> 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.
> 
> > 5) External programs not aware of the database can still use the sources
> > directly. Well it may happen that we move functions_basic to a separate file
> > though.
> 
> 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.

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.

> > Function: bnfinit
> > List: basic
> > Section: 6
> > C-Name: bnfinit0
> > Prototype: GD0,L,DGp
Sorry I removed the 'Help:' entry with the short online help.
We have not yet settle on the long online help (in a Doc: entry).
Also planned is a Description: field for GP2C.

For the Mod() function this field look like

Function: Mod
Description:
 (small,small):gen       gmodulss($1, $2)
 (small,gen):gen         gmodulsg($1, $2)
 (gen,gen):gen           gmodulcp($1, $2)
 (small,small,0):gen     gmodulss($1, $2)
 (small,gen,0):gen       gmodulsg($1, $2)
 (gen,gen,0):gen         gmodulcp($1, $2)
 (gen,gen,1):gen         gmodulo($1, $2)
 (gen,gen,small):gen     Mod0($1, $2, $3)

I am currently writing a memo about what this means for GP2C, though this
particular example is ``pretty obvious'' in the sense of, if you manage to give
it a sense, it is probably the good one. One goal is to consider this field
as a part of the documentation and not only GP2C specific. We can even
pretty-print it to output in TeX in a more readable form.

> I would prefer
> 
>   Prototype: GD0,L, DG p

I am trying to design a new format that will allow to generate bona-fide protocode,
but would be more readable to humans. Something like (gen,long?0,gen?,prec).
But this is not finished, so in the meantime we stick with standard GP protocode.

I don't want to put too many think depending on GP2C-style type in the database
for now, so...

> > Type: gen
> 
> Is this to replace v and l tokens?

Not decided yet.

Cheers,

Bill.