Re: [PATCH 2.2.2] mnemonics for flags

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

On Wed, Jun 26, 2002 at 03:35:41PM -0400, Ilya Zakharevich wrote:
> On Wed, Jun 26, 2002 at 07:08:42PM +0200, Bill Allombert wrote:
> > > This is not what you wrote - and not what actually happens: with 'M'
> > > the compile-time optimization is possible, with 'G' not.
> > 
> > You can do it in both cases. GP2C already do it for type values.
> 
> > % echo 'type(x)=="STR"' | gp2c | grep STR
> >   typ(x) == t_STR;
> 
> The diffence is that in the former case no change to gp2c is needed
> when a new flag-capable function is coded.

It makes no difference. In both case you have to update the gp2c functions
description file to let gp2c knows about the new definition. 

This file is automatically build from the PARI/GP source. If we add a way to
specify symbolic flags in PARI, gp2c should be able to read it and add it
to its functions description file.

Anyway if flag names are t_STRING, using G or M does not make a real difference.
It is merely aesthetic. 
There are some ambiguity in the parser code system.
DGD0,L, is parsed as (GEN x1 /*default NULL*/ , long x2 /*default 0*/ )
but it can also be understood as (GEN long x1 /*default to GD0*/).
I would prefer to keep it simple.

> > Providing a interface definition via enum type or #define definition only
> > require an ANSI C compiler to have a translation between option name and
> > numerical value.
> 
> How do you perform operations over enums with a check of validity of
> the operation?

That's a good point for you. What kind of check do you want to perform ?
Can you do it with the current numeric flag interface ?
Using sufficiently explicit enum value name, we should be able to avoid 
most mistakes (but not to *check* them, agreed).

Cheers,

Bill.