Re: Interface definition for PARI/GP

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

On Wed, Jul 03, 2002 at 11:15:14PM +0200, Bill Allombert wrote:
> > > 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.

Thanks.  Keep in mind that one part of Math::PariBuild is not cleaned
up from the (initial ;-) mess state.  But I think that the part in
question is completely modulirized and documented now.  [IIRC, the
mess part coincides with undocumented stuff, so it should be easy to
distinguish them.]

> 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 ?

In the Math::Pari hat, I do not care much for the old system - as far
as I do not need to spend a lot of time for updating Math::Pari ;-).
In the PARI hat, I would prefer

  a) Have PARI core rewritten in C, or at least allow new code to be
     written in C;

     [As opposed to the current situation, when the core is written in
     an assembler disguised as C.]  A couple of years ago I already
     sent a patch to implement a typedef()ed type system for PARI.

     [IIRC, the objection of that time was that the patch did not work
     if sizeof(long) != sizeof(long*).  This objection is easy to
     overcome if one accesses vector's elements by a macro: then one
     can put union {long dummy; PARI_t elt;} as an element of vector
     types - for the duration of the transition period to the new type
     system ...]

     This should be accompanied by new macros for allocation of
     objects and access to object fields which is independent of the
     internal structure of object.  Of course, there should be an
     opaque type PARI_t which can be casted to different types basing
     on typ(obj)...

  b) When we have a finer-granularity C type system, use this type
     system for finer C signature of PARI library functions.

Ilya