Re: 22- polgalois()

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

On Thu, 13 Jun 2002 allomber@math.u-bordeaux.fr wrote:

> On Wed, Jun 12, 2002 at 07:02:53PM +0200, Karim BELABAS wrote:
> > I fear this is quite convincing.
> >
> > OK, I've undone the polgalois() change, so that the old naming scheme is back
> > in effect (sigh). There's a new boolean default new_galois_format: if set to
> > true, you'll get the new format [set to false = 0] by default. I will
> > eventually set it to true, someday.
>
> The standard way to handle compatibility is to define increasing compatibility
> level and to default to the highest supported.
>
> Something like:
> GP 1.39 level 0
> GP 2.1  level 1
> GP 2.3  level 2
>
> so that scripts can start with
> default(compat,N)
> to specify the compat level they need.

The problem is that there are many, completely orthogonal, compatibility
problems (I mentioned just a few in pari-dev-1411), and users might feel
confortable with some but not all of these. I can't figure a simple ordering
scheme as above, it's really a collection of independant toggles, which would
all default to the current [ unsatisfactory ] behaviour.

> Unfortunately the GP compat level is decreasing and we are
> already at 0...
>
> Also 2.2 already have several incompatibilities anyway for which we do not
> provide compatible alternatives, unfortunately.

Now might be a good time to list them. ( Anything not in COMPAT ? ) And to try
and plan what else we want to change about gp.

The library compatibility problem is of a quite different nature since we
want to redesign (and make public) a large number of interfaces, hence bump
the version number anyway. This was already done for GP-2.1.0, when
practically every single function changed, without major disasters, and
actually surprisingly few complaints. But that was never done for the
library.

Also, whereas gp is thriving, libpari is dying (besides its use through gp):
very few people actually use it now, for a number of good and bad reasons
which we might want to discuss in another thread.  Besides Math::Pari, I
don't know of any publicly available package that rely on libpari
_programming_. ( There are systems linking to libpari in order to use one or
two very high-level routines. These would not be affected by the changes we
have done, or plan to do. )

Changing the API might make libpari a more popular choice (or kill it
outright, granted). In any case, _we_ want to continue using libpari if only
to develop high-level gp routines, and I would like to be comfortable doing
so, with appropriate structures, aptly named (correctly documented) routines
and so on.

> Maybe new_galois_format can simply be a flag to polgalois() instead ?

It would be too cumbersome. I'd expect a user would set such a default once
and for all in a .gprc [ or not at all and rely on the default, until the
next major version change where we would invert default values for these
toggles ]. A script or package needing specific behaviour should save the
user environment, set its own defaults, and restore upon exit (implemented as
a bitfield of flags, it would not cause any performance penalty).

I've already eliminated most of the static global variables in gp.c (still in
progress), it should be relatively easy to do now. [ I wanted to remove
practically everything from gp-specific files, and move the code to the
library. Only main() and readline-related stuff would remain. We need library
interfaces to practically all gp routines, including iterators (done in my
private sources, but very buggy, I dare not commit yet), plot, etc. ]

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/