You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This pseudo-AST structure described in #179 could also be the foundation of a useful advanced feature from PCRE, Perl, etc.: The ability to reference the entire contents of a named or numbered group (including nested parens) from later in the pattern, enabling support for subpattern reuse via (?&name) and (?n).
This would simply require generic syntax tokens for ) and any ( that isn't part of a self-contained token like (?#...) to mark subsequent tokens as children until the closing ) arrives. Then the generated pattern contents of each named group could be derived when needed.
An error would need to be thrown if the group name referenced by (?&name) or group number with (?n) was not yet closed.
Make sure to handle things like (?<$1>.)(?<$2>(?&$1))(?&$2).
Some of the use cases are already handled by XRegExp.build and XRegExp.tag, but this would still be cleaner and or more robust in some cases, and the foundation created for it would make potential future XRegExp syntax addons more powerful.
The text was updated successfully, but these errors were encountered:
This pseudo-AST structure described in #179 could also be the foundation of a useful advanced feature from PCRE, Perl, etc.: The ability to reference the entire contents of a named or numbered group (including nested parens) from later in the pattern, enabling support for subpattern reuse via
(?&name)
and(?n)
.This would simply require generic syntax tokens for
)
and any(
that isn't part of a self-contained token like(?#...)
to mark subsequent tokens as children until the closing)
arrives. Then the generated pattern contents of each named group could be derived when needed.Perhaps this would look like:
Notes:
(?&name)
or group number with(?n)
was not yet closed.(?<$1>.)(?<$2>(?&$1))(?&$2)
.XRegExp.build
andXRegExp.tag
, but this would still be cleaner and or more robust in some cases, and the foundation created for it would make potential future XRegExp syntax addons more powerful.The text was updated successfully, but these errors were encountered: