Piraha Parser Discussion
It was suggested that a new improved parser format be put forward, one closer to python.
- New format tag at the top to allow backwards compatibility
- RH: possibly in the form similar to activethorns, ie like a global parameter but that is required to be first in the file
- Or could be a structured comment starting with an exclamation mark
- SB: How about "!PARSER VERSION=1.0"
- Require triple quotes for multiline quotes
- Require quotes for all strings and keywords
- Disallow quotes for integers and reals
- Require yes/no for booleans
- RH: allowing 1/0 can be useful for parameter file scripts since then the same variable can be used in the scripting languages "if" statement and in the Cactus parameter file (since both "yes" and "no" tend to evaluate as logical true in these languages).
- SRB: We could standardize on True/False instead, if we want to be Python-like.
- compiled() option to provide compiled-in values for parameters
- ES: I prefer the name "fixed" over "compiled", and it doesn't need to look like a function call, it should be more like an attribute of a parameter
- SB: When I hear "fixed" I think of it in contrast to "broken." But maybe it's just me. When you say "attribute" do you mean something like "@fixed thorn::par = 3"?
- Could have a different format for lists (i.e. ActiveThorns and list of variables that should be output) that doesn't require multi-line strings; this could instead be a list of strings (using e.g. square brackets and commas), which is then converted to a single string after parsing
- This would also get rid of comments-in-strings, and possible multi-line comments
- SB: We have a funny way of handling lists. In some places, a string is used as a list, in other places we have strings with square brackets. Currently, I translate "foo::bar = [1,4,9]" to "foo::bar=1 foo::bar=4 foo::bar=9". I could translate "[1,4,9]" to " 1 4 9 " if the type of the variable is a string. This feels kind of hacky though.
- Could allow "+=" with such lists, so that they don't have to be defined in a single place; this would be useful for I/O variable lists
- The "=" sign should be mandatory when setting parameters
- RH: when outputting error messages, include the column number as well as the line number (rather than just the caret indicator) this makes it easier to parse the error in an editor/ide and also in not prone to line breaking/variable character width/mail program indentation issues.
- ES: Final newline should be required.