[Developers] Re: refine the syntax of parameter files

Jian Tao jtao at artsci.wustl.edu
Tue Aug 24 15:28:53 CDT 2004


>> #parameter_names can only be one or multiple valid parameter_name's
>>    7  parameter_names
>>                      : parameter_name
>>    8                | parameter_names TOK_COMMA parameter_name
>
>Is this currently allowed?  If not, it would also be an addition.  Given
>that many parameter names are quite long, I don't think that this is
>useful in practice; we're having trouble enough fitting a single
>parameter definition onto one line.

It is allowed, although not so many people are using it. Tom wants
to leave it there anyway. It's not my fault. ;)

>> #parameter_name should be name or
>> #[a-zA-Z][a-zA-Z0-9_]*::name
>>    9  parameter_name
>>                      : name
>>   10               | TOK_STRING TOK_DOUBLE_COLON name
>
>Why this?  The left hand side should be something like
>
>	thorn::name
>
>and not only a name.

This is to allow global parameters.

>> #refer to parameter_names
>>   13  parameter_vals
>>                      : parameter_val
>>   14               | parameter_vals TOK_COMMA parameter_val
>
>Ditto.
>
>> #valid_string could be "whatever" or [a-zA-Z][a-zA-Z0-9_]* or
>> # [a-zA-Z][a-zA-Z0-9_]*::[a-zA-Z][a-zA-Z0-9_]*
>>   18  valid_string
>>                      : TOK_QUOTED
>>   19               | name
>>   20               | TOK_STRING TOK_DOUBLE_COLON name
>
>The right hand side can be a number or a string, it cannot contain
>double colons nor brackets.

I did see this in a parameter file which was accepted by Cactus.
If strings were enclosed by quotes we should have only
one line TOK_QUOTED.

>I can think of several other things that should be improved in parameter
>files, e.g. not having to repeat thorn/implementation names to the left
>of the scope operator,

This can be done similar to defining the scopes in interface.ccl

>or how to handle long strings that span multiple lines,

This will not be a problem if they are enclosed in quotes. '\' is
discarded anyway. It is not necessary to type it for each line.

>or setting multiple parameter array elements at once,

If you mean something like this :
foo = "v0,v1,v2"
which sets foo[0]="v1" and etc.
This could be done as long as the seperator, which is ',' in the example,
is unique.

> or introducing variables/defines,

This is similar to
!DESC "description", which was considered in the parser modified for
Cactus Portal.
We can define a variable by
!DEFINE $parfile or something similar.

> or changing the way the lists of output
>variables are constructed,

There are various ways to do it. We probably need a poll for it.

>or allowing parameters to be grouped so that
>the name space is smaller, or...

That is a good idea, but I don't understand how Cactus can make use of
this group property. Furthermore, different users may have their own
preferences to group parameters.

>I very much like the idea to have a formal specification, and a tried
>tool to create the parser.  Better error messages and fewer arbitrary
>limitations would be one benefit.

As a matter of fact, we currently have tools(based on lex & yacc) to
parse all the CCL files as well. However we have much more problems
related to the CCL syntax as you may expect.

Jian
 -------------------------------------------------------------
 Jian Tao, WUGRAV, Washington University,
 St. Louis, MO, 63130   tel: 314-935-8812
 email:    jtao at wugrav.wustl.edu
 -------------------------------------------------------------



More information about the Developers mailing list