Re: [PATCH 2.2.2] mneumonics for flags

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

On Wed, Jun 26, 2002 at 11:48:58AM -0400, Ilya Zakharevich wrote:
> On Wed, Jun 26, 2002 at 04:37:40PM +0200, Bill Allombert wrote:
> > > As far as I can see it, the M flag for arguments is not included in
> > > 2.2.3.  Any particular reason for this?
> 
> > 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.
> 
> This is not anything new: a lot of arguments are treated similarly:
> 
>  default(Runge-Kutta/Known-Prime, 1)
>   ***   unknown default: Runge-Kutta/Known-Prime.

That does not prove this is a *good* thing.  Beside, The "r" prototype accept
*only* keyword, not both expression/numbers and keywords, so there is no real
ambiguity. 

Also the following command are the only one to use the "r" keyword:
alias,install,type,default,trap,whatnow.

> > 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
> 
> Of course you can.  All that is needed is extending the logic to treat
> t_STRING arguments similarly.  (Do not remember whether this is
> already present in the patch, but this is trivial to patch.)

I would prefer that only t_STRING is used. Then we can use a standard "G"
prototype code, and there is no ambiguity.

> 
> > 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.
>
> See default()

The only reason default use keyword is that the input would be converted to
string anyway (not to a number). So using realprecision instead of
"realprecision" would work, with the annoying side-effect of creating a
variable with name realprecision.

Anyway I would prefer the "r" code be removed in favour of the "s" one.

>
> > With the GP2C parser, post-processing can easily be implemented to
> > translate flag string into numerical value at compile time.
> 
> I'm confused: Is not this a plus?

What I meant is that using t_STRING instead of keyword make no performance
penalty for both system.

> 
> > 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.
> 
> ???  The parse_option_string() API is available...

Parsing options string at run time is not desirable. Option should be converted
to numeric at compile time.

We need to be careful when adding a new interface to GP if we want to
be able to maintain compatibility with it in the future.

Cheers,

Bill.