Re: [PATCH 2.2.2] mnemonics for flags

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

On Thu, Jun 27, 2002 at 01:34:52PM +0200, Bill Allombert wrote:
> > 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.

As I said: *this* is the difference.  With "M Pattern", there is way
for the external program to precompile the mneumonic flags.  With "G",
one needs some additional way to allow this.

> Anyway if flag names are t_STRING, using G or M does not make a real
> difference.

Of course it does.  E.g., Math::Pari converts an argument of type
"String" to G via lisexpr().  Doing this over a mneumonic flag would be
a disaster.  Thus a special flag is needed anyway (call it "M" for the
sake of discussion).

Three intertwined questions remain:

  a) Should the "pattern" for the flags be exposed via the struct entree;

  b) Should the corresponding C function take a long or a GEN;

  c) Should the pattern be embedded into the argument signature
     string, or be available elsewhere?

If a==NO, then b==GEN, and "c" is N/A.  As I already discussed it,
this requires the compiler to be changed each time the pattern is
changed.

So I assume a=YES.  Then there is no *need* to change the signature of
the libPARI function each time a particular numeric flag is upgraded
to a mneumonic flag.  Thus Occam razor says b==LONG.

"c" is the hard one.  It is irrelevant for the compile-to-C solutions,
but gp (and the current implementation of Math::Pari, which processes
"rare" signatures at run time) will need to skip the pattern (until
the next ',') when the actual argument is "numeric".

In my implementation c==embedded.  This leads to the overhead above;
on the other hand, AFAIU, this overhead must be negligible: I assume
that flags are needed only in the case when the actual work done by
the function is not-trivial; thus skipping even over a long pattern
would not slow things noticeably.

> 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*/).

No ambiguity: a default for a long should be a long, and GD0 isn't.
[But I also look at "DG" with suspicion; note that it was not in the
initial implementation I did; I would prever it to be denoted as "D,G"
or some such.  There may be other examples with a *legitimate* ambiguity.]

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

See my initial message.  There are two safeguards:

 "Set to a value" should be done first (may be followed by |-type and
      &~-type modifiers;

 "Set to a value and that's it" may be used standalone only.

AFAIU, this is all what is needed with the current PARI API, and with
other flag-taking API I had seen in my life.

> 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).

Enum do not even come close.  You need to remember which flags require
ORing, which ANDing.

Ilya