mworks/mworks — pull request #7 by cstawarz (2012-08-01 16:54:31+00:00)
Title: Expression parser improvements

Some enhancements involving the expression parser:

* The following operators and literals, which were previously handled via textual substitution, are now properly recognized and handled by the expression parser:
* Boolean literals `true`, `false`, `YES`, `NO` (not case sensitive)
* Logical operators `#AND`, `#OR`
* Comparison operators `#GT`, `#LT`, `#GE`, `#LE`
* Time units `us`, `ms`, `s` (treated as unary postfix operators)

* The expression parser now handles `not`, `and`, and `or` like other keywords (e.g. it recognizes that `notx` is not the same as `not x`)

* Range replicator parameters "from", "to", and "step" can now be arbitrary expressions

* The expression parser now recognizes integer range expressions (e.g. `1:3` is equivalent to `1,2,3`). Selection variables now support range expressions in the values list. Mixed expressions (e.g. `1,2,3:5,6,7:10`) are also supported.

* The expression parser now supports variable subscript expressions (e.g. `foo[bar]`). For non-selection variables, any attempt to evaluate such an expression raises a BadVariableSubscriptException.

* The expression `sel[n]`, where "sel" is a selection variable, now returns the "n"th tentative (i.e. non-accepted) selection. If "n" is less than zero or greater than the number of tentative selections, the expression evaluates to 0 and logs an error message.

* Some refactoring and cleanup in ComponentRegistry, VariableRegistry, SelectionVariable, and ParsedExpressionVariable

Although the indexing of selection variables is a user-requested feature, I have my doubts about its value. Also, since all expressions are evaluated at experiment load time, the presence of selection variable indexing expressions always causes errors when loading the experiment, as nascent selection variables have no tentative selections. As such, I could be convinced that this feature should be dropped.