[Developers] refine the syntax of parameter files

Erik Schnetter schnetter at aei.mpg.de
Tue Aug 24 03:35:49 CDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 24 August 2004 09:47, Jian Tao wrote:
> #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.

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

> #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 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, or how to handle long strings that span multiple 
lines, or setting multiple parameter array elements at once, or 
introducing variables/defines, or changing the way the lists of output 
variables are constructed, or allowing parameters to be grouped so that 
the name space is smaller, or...  It would be nice if these issues were 
also mentioned, so that one wouldn't need several successive changes to 
parameter files in order to address all these idea.

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.

- -erik

- -- 
Erik Schnetter <schnetter at aei.mpg.de>   http://www.aei.mpg.de/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBKv3lm3uiSwno3f0RAnwVAJwOyDszKaFijmSFX7GwkWyw9IMlXwCgrSh7
KhJPoG1muNMSEwWxwa07OqI=
=6fmR
-----END PGP SIGNATURE-----





More information about the Developers mailing list