Re: gnil

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

On Tue, Sep 10, 2002 at 05:14:11PM +0200, Karim BELABAS wrote:
> On Tue, 10 Sep 2002, Bill Allombert wrote:
> I forgot I had removed it from the public headers... [ it's declared in anal.h ]
> 
> (16:53) vintsy-karim% cat >test.c <<EOF
> #include<pari/pari.h>
> extern GEN gnil;
> GEN f(GEN x) { return gcmp0(x)? gnil: gun; }
> main(){}
> EOF
> (16:53) vintsy-karim% gcc test.c -lpari -lm
> (16:53) vintsy-karim%
> 
GP2C is not going to use private symbols, so currently I am stuck, at least
for PARI 2.1 compatibility.

> 
> OK, yet another good reason to write a separate header file declaring "private"
> exported symbols (and types), say paripriv.h  [ still the stupid old 8.3 DOS
> limit ]
> 
> Logic would be that
> * paridecl.h contains only functions with documented API [ we'd
> guarantee stability there ]
> 
> * paripriv.h contains undocumented stuff, for which we guarantee nothing.
> pari.h would contain something like
> 
> #ifdef PARI_USE_PRIVATE
> #  include <paripriv.h>
> #endif
> 
> So we could
> 1) remove all the "extern ..." declarations currently scattered everywhere
> 2) move all undocumented stuff from paridecl.h to paripriv.h [ or document
> them immediately ]
> 3) start documenting things from paripriv.h and move them to paridecl.h
> 
> Cheers,
> 
>     Karim.
> 
> P.S: Not sure whether paripriv.h should be a wrapper including a bunch of
> individual header files, or monolithic like paridecl.h.

I would prefer both paripriv.h and paridecl.h be wrappers to individual header
files.  In fact I would like pari source being splitted in much more files
with definite purposes and interfaces in-between.

Also some headers files could be generated by the description system to force
consistency between the descriptions and the actual code.

The GNU coding standards propose to put every exported symbols in a separate source
file for a better static linking. Maybe it is an extrem position for PARI, but we
are very far from that currently.

Cheers,
Bill