Alright let's see if we can find a middle ground here so I only have to change the parser once - at the risk of
bikeshedding.
Since we all agree on the '[ { lines | items | items in lines } of ]' part as well as the '[ into <container> ]' part, I'll leave these out of the discussion below.
Idea
We could treat 'with' and 'matching' as synonyms, and of course likewise 'without' and 'not matching'.
And to clarify the 'pattern' to use, we introduce 'wildcard' as adjective for the old filter pattern mechanism, and 'regex' for regular expression pattern matching.
Then the script line:
would be equivalent to both of the following verbose variants:
Code: Select all
filter tText with wildcard pattern "*text"
filter tText matching wildcard pattern "*text"
And the script line:
would be equivalent to both of the following verbose variants:
Code: Select all
filter tText without wildcard pattern "*text"
filter tText not matching wildcard pattern "*text"
Now to use regular expression matching you could write either of the following:
Code: Select all
filter tText with regex pattern ".*text"
filter tText matching regex pattern ".*text"
And you can reverse the filtering by writing either of the following:
Code: Select all
filter tText without regex pattern ".*text"
filter tText not matching regex pattern ".*text"
Syntax
The BNF for this part of the 'filter' command would then become:
Code: Select all
filter ... <container_or_exp> { with | without | [ not ] matching } [ { wildcard | regex } pattern ] <pattern_exp> ...
Resulting in the complete BNF for the 'filter' command as follows:
Code: Select all
filter [ { lines | items | items in lines } of ] <container_or_exp> { with | without | [ not ] matching } [ { wildcard | regex } pattern ] <pattern_exp> [ into <container> ]
This gives us backward compatibility and allows each developer to match it up with their programming style (pun intended).
And Mark Waddingham can decide which forms survive in the 'new syntax' project and how it's converted
Boot note: related language items
Remember that while wildcard matching is not as powerful as regex matching, it has better performance, so we may want to carry this over to related language items already mentioned before.
We could introduce a 'matches' operator with similar options
Code: Select all
if tText matches wildcard pattern "*text" then...
if tText matches regex pattern ".*text" then ...
And extend the 'replace' command likewise with both wildcard and regex matching if it makes sense.
Jan Schenkel.