|Bill Allombert on Wed, 26 Jun 2002 18:19:57 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PATCH 2.2.2] mneumonics for flags|
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.