Bill Allombert on Tue, 19 Nov 2002 16:30:34 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: GP as a programming language

On Fri, Nov 15, 2002 at 01:40:44PM -0800, Ilya Zakharevich wrote:
>   [Subject changed; in the middle of composing the previous message I
>    changed my mind what should the focus of the message, but forgot to
>    change the subject.]
> On Fri, Nov 15, 2002 at 01:21:31PM +0100, Bill Allombert wrote:
> > On Thu, Nov 14, 2002 at 06:28:31PM -0800, Ilya Zakharevich wrote:
> > > I think that the principal reason for slow uptake of GP/PARI is how
> > > painful it is to extend it.  When one extends in C, one needs to fight
> > > with PARI being so C-hostile [one essentially program in assembler,
> > > using (GEN)z[n] instead of z->array[n] - or at least VEC_elt(z,n) as
> > > in my recent patch; likewise for access to components of other types]
> > > and the API is so un-mneumonic.  It is very hard to read existing code
> > > (to improve, or to model one's own code on an existing one).
> > 
> > That is what of the point of writing GP2C.
> See the end of my previous message.  gp2c is in the same ballpark as
> Math::Pari.  Math::Pari did not help GP/PARI.  I see no reason why
> gp2c would.

gp2c allow to produce C code from GP code more easily. You do not need
to care about the PARI syntax since gp2c handle this for you.
If you have a working GP script you can use gp2c to translate it to C
code and then add it to PARI. The file src/basemath/perm.c was done this way.
So I believe it make extending PARI/GP easier.