Re: Description system TODO list

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

Hello PARI developers,
I plan to fix the outstanding problems preventing release of
PARI 2.2.7 and to allow gp2c to be compatible with PARI 2.2.7.

> Here a list of issues that need to be ironed out
> with the description system:
> 
> 1) Changing a src/functions/xxx/yyy file does not trigger the rebuild
> of src/desc/Def file. This is painful with CVS.

I believe this is fixed for good now. 

> 2) This is a good time to get rid of 'valences'.

Done. 

> 3) 'make install' should install sufficient data to build GP2C
> in a fixed location:
> dft.Config.in,src/desc/Def and probably src/desc/PARI/822.pm.

That needs to happen. We have essentially to decide where we put the data.

dft.Config.in belong to /usr/lib/pari. Maybe 
/usr/lib/pari/pari.cfg

src/desc/Def belong to /usr/share/pari. Maybe
/usr/share/pari/interface.gz

We can eventually rename Def to something else.

src/desc/PARI/822.pm belong to /usr/share/pari/PARI/822.pm 
unless we want to make it available to regular perl use (?)

[BTW, if a perl expert could review the perl scripts to tell us
what version of perl is required and what we can do about this,
I will appreciate greatly.]

Do you have idea for better name/path ?

> 4) Make GP2C to use the above.

This is implemented but not commited to CVS.

> 5) Fix Math::PARI to use the above. (Ilya, my offer to help still stand).

I suppose this wait for 3).

> 6) Add the Description: material in GP2C to GP.
Partly done, but there still some missing data:
1) Operators (+,-,&&,etc.) definition.
2) Member functions.
3) extra GP2C function.
4) internal GP2C interface.

1) I propose we add a directory symbolic_operators
with file name named after the name of the PARI function without the g prefix.
(add, sub, etc.). Inside we use the GP2C name of the operator (_!,_+_)
as Name:. This avoid having non alphanumeric characters in filename.
(And anyway _/_ is not a valid UNIX filename).

Operators will need to live in a new Class: to not be read by GP.

2) I would like we chage the way member functions are handled inside
GP to be just regular function named _.xxx in the database.
When a.xxx is called, gp look up _.xxx in the database and call it.
This would allow to install member function directly with install()
and simplify handling a bit. In particular member function will not
need to live in a new Class:

3) extra GP2C functions. They are functions usefull with gp2c but close
to noop with GP, like gcopy. I will add them in a new class, though it
would be nice to be able to activate them under GP for testing GP
scripts that use them. Class: gp2c

4) internal GP2C interface. This is implementation of some gp2c
interface that may depend of the PARI version. Class gp2c_internal.

In short I propose to add 4 directories:
functions/symbolic_operators Class: operators
functions/member_functions  
functions/gp2c               Class: gp2c
functions/gp2c_internal      Class: gp2c_internal

Comments ?

> 7) Document the Description: field format.
I have written such a document. I will release it at some point
(but please ask me a copy if you need it).

> We can also add 'disabled' C-function in the interpretor that can
> be enabled wih install() without the need for the prototype.

I would like we implement this one. It can be especially useful
on platform where install() does not work by adding the pointer
to the function in the gp binary instead of dlopen() it.

Cheers,
Bill.