Re: [PATCH 2.2.2] mneumonics for flags

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

On Wed, Jun 26, 2002 at 09:07:03AM -0400, Ilya Zakharevich wrote:
> On Fri, Jan 11, 2002 at 09:21:20PM -0500, Ilya Zakharevich wrote:
> > This patch adds a possibility to use mneumonic flags instead of
> > numberic flags.  E.g., instead of 
> > 
> >   6+1024
> > 
> > one can use
> > 
> >   Runge-Kutta/Known-Prime
> > 
> > (for a silly example ;-), if the correponding function descriptor uses
> > "MRunge-Kutta=6;Known-Prime|1024" instead of "L".
> 
> As far as I can see it, the M flag for arguments is not included in
> 2.2.3.  Any particular reason for this?

Yes, probably.

1) This patch create ambiguities in the GP grammar.
Runge-Kutta/Known-Prime is already a valid GP expression.
Giving it a different meaning in some context is creating ambiguities.

2) You cannot store flag values in variable, so something like
flag=6; if(x==1,flag+=1024) 
cannot be translated to use symbolic flag

With the current way GP parse its code, there is no performance penalty
to put Runge-Kutta/Known-Prime in a string "Runge-Kutta/Known-Prime",
which resolves the ambiguity.

With the GP2C parser, post-processing can easily be implemented to
translate flag string into numerical value at compile time.

Also strings can be stored in variable, so the above example can be 
rewritten as

flag="Runge-Kutta"; if(x==1,flag=concat(flag,"/Known-Prime"))

3) This patch does not provide a similar interface to libpari programming.
It is important that libpari and GP interface are kept on a par.

It should be easy to do via enum type or #define, but Runge-Kutta is not a
valid enum or #define name, and the value must be independant of the plotting
function at hand. We can use prefix to separate name space, though.

However having a general way to handle symbolic flags would be useful.
but there are several thing to consider, such as which syntax to use,
how symbolic flag are evaluated, how to implement them, etc...

Cheers,

Bill.