[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
>> #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 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