txt: ## regexes.md
  ## Chunk 4 of 5
   view.
  
  In particular the `<?{}>` operator requires a `True` value in order to allow the regular expression to match, while its negated form `<!{}>` requires a `False` value.
  
  In order to demonstrate the above operator, please consider the following example that involves a simple IPv4 address matching:
  
  ```raku
  my $localhost = '127.0.0.1';
  my regex ipv4-octet { \d ** 1..3 <?{ True }> }
  $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
  say $/<ipv4-octet>;   # OUTPUT: «[｢127｣ ｢0｣ ｢0｣ ｢1｣]␤»
  
  ```
  
  The `octet` regular expression matches against a number made by one up to three digits. Each match is driven by the result of the `<?{}>`, that being the fixed value of `True` means that the regular expression match has to be always considered as good. As a counter-example, using the special constant value `False` will invalidate the match even if the regular expression matches from a syntactic point of view:
  
  ```raku
  my $localhost = '127.0.0.1';
  my regex ipv4-octet { \d ** 1..3 <?{ False }> }
  $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
  say $/<ipv4-octet>;   # OUTPUT: «Nil␤»
  
  ```
  
  From the above examples, it should be clear that it is possible to improve the semantic check, for instance ensuring that each *octet* is really a valid IPv4 octet:
  
  ```raku
  my $localhost = '127.0.0.1';
  my regex ipv4-octet { \d ** 1..3 <?{ 0 <= $/.Int <= 255 }> }
  $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
  say $/<ipv4-octet>;   # OUTPUT: «[｢127｣ ｢0｣ ｢0｣ ｢1｣]␤»
  
  ```
  
  Please note that it is not required to evaluate the regular expression in-line, but also a regular method can be called to get the Boolean value:
  
  ```raku
  my $localhost = '127.0.0.1';
  sub check-octet ( Int $o ){ 0 <= $o <= 255 }
  my regex ipv4-octet { \d ** 1..3 <?{ &check-octet( $/.Int ) }> }
  $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
  say $/<ipv4-octet>;   # OUTPUT: «[｢127｣ ｢0｣ ｢0｣ ｢1｣]␤»
  
  ```
  
  Of course, being `<!{}>` the negation form of `<?{}>` the same Boolean evaluation can be rewritten in a negated form:
  
  ```raku
  my $localhost = '127.0.0.1';
  sub invalid-octet( Int $o ){ $o < 0 || $o > 255 }
  my regex ipv4-octet { \d ** 1..3 <!{ &invalid-octet( $/.Int ) }> }
  $localhost ~~ / ^ <ipv4-octet> ** 4 % "." $ /;
  say $/<ipv4-octet>;   # OUTPUT: «[｢127｣ ｢0｣ ｢0｣ ｢1｣]␤»
  
  ```
  
  # [Adverbs](#Regexes "go to top of document")[§](#Adverbs "direct link")
  
  Adverbs, which modify how regexes work and provide convenient shortcuts for certain kinds of recurring tasks, are combinations of one or more letters preceded by a colon `:`.
  
  The so-called *regex* adverbs apply at the point where a regex is defined; additionally, *matching* adverbs apply at the point that a regex matches against a string and *substitution* adverbs are applied exclusively in substitutions.
  
  This distinction often blurs, because matching and declaration are often textually close but using the method form of matching, that is, `.match`, makes the distinction clear.
  
  ```raku
  say "Abra abra CADABRA" ~~ m:exhaustive/:i a \w+ a/;
  # OUTPUT: «(｢Abra｣ ｢abra｣ ｢ADABRA｣ ｢ADA｣ ｢ABRA｣)␤»
  my $regex = /:i a \w+ a /;
  say "Abra abra CADABRA".match($regex,:ex);
  # OUTPUT: «(｢Abra｣ ｢abra｣ ｢ADABRA｣ ｢ADA｣ ｢ABRA｣)␤»
  ```
  
  In the first example, the matching adverb (`:exhaustive`) is contiguous to the regex adverb (`:i`), and as a matter of fact, the "definition" and the "matching" go together; however, by using `match` it becomes clear that `:i` is only used when defining the `$regex` variable, and `:ex` (short for `:exhaustive`) as an argument when matching. As a matter of fact, matching adverbs cannot even be used in the definition of a regex:
  
  ```raku
  my $regex = rx:ex/:i a \w+ a /;
  # ===SORRY!=== Error while compiling (...)␤Adverb ex not allowed on rx
  
  ```
  
  Regex adverbs like `:i` go into the definition line and matching adverbs like `:overlap` (which can be abbreviated to `:ov`) are appended to the match call:
  
  ```raku
  my $regex = /:i . a/;
  for 'baA'.match($regex, :overlap) -> $m {
      say ~$m;
  }
  # OUTPUT: «ba␤aA␤»
  ```
  
  ## [Regex adverbs](#Regexes "go to top of document")[§](#Regex_adverbs "direct link")
  
  The adverbs that appear at the time of a regex declaration are part of the actual regex and influence how the Raku compiler translates the regex into binary code.
  
  For example, the `:ignorecase` (`:i`) adverb tells the compiler to ignore the distinction between uppercase, lowercase, and titlecase letters.
  
  So `'a' ~~ /A/` is false, but `'a' ~~ /:i A/` is a successful match.
  
  Regex adverbs can come before or inside a regex declaration and only affect the part of the regex that comes afterwards, lexically. Note that regex adverbs appearing before the regex must appear after something that introduces the regex to the parser, like 'rx' or 'm' or a bare '/'. This is NOT valid:
  
  ```raku
  my $rx1 = :i/a/;      # adverb is before the regex is recognized => exception
  
  ```
  
  but these are valid:
  
  ```raku
  my $rx1 = rx:i/a/;     # before
  my $rx2 = m:i/a/;      # before
  my $rx3 = /:i a/;      # inside
  ```
  
  These two regexes are equivalent:
  
  ```raku
  my $rx1 = rx:i/a/;      # before
  my $rx2 = rx/:i a/;     # inside
  ```
  
  Whereas these two are not:
  
  ```raku
  my $rx3 = rx/a :i b/;   # matches only the b case insensitively
  my $rx4 = rx/:i a b/;   # matches completely case insensitively
  ```
  
  Square brackets and parentheses limit the scope of an adverb:
  
  ```raku
  / (:i a b) c /;         # matches 'ABc' but not 'ABC'
  / [:i a b] c /;         # matches 'ABc' but not 'ABC'
  ```
  
  Alternations and conjunctions, and their branches, have no impact on the scope of an adverb:
  
  / :i a | b c /; # matches 'a', 'A', 'bc', 'Bc', 'bC' or 'BC' / [:i a | b] c /; # matches 'ac', 'Ac', 'bc', or 'Bc' but not 'aC', 'AC', 'bC' or 'BC'
  
  When two adverbs are used together, they keep their colon at the front
  
  ```raku
  "þor is Þor" ~~ m:g:i/þ/;  # OUTPUT: «(｢þ｣ ｢Þ｣)␤»
  ```
  
  That implies that when there are multiple characters together after a `:`, they correspond to the same adverb, as in `:ov` or `:P5`.
  
  ### [Ignorecase](#Regexes "go to top of document")[§](#Ignorecase "direct link")
  
  The `:ignorecase` or `:i` adverb instructs the regex engine to ignore the distinction between uppercase, lowercase, and titlecase letters.
  
  See the [section Regex adverbs](/language/regexes#Regex_adverbs) for examples.
  
  ### [Ignoremark](#Regexes "go to top of document")[§](#Ignoremark "direct link")
  
  The `:ignoremark` or `:m` adverb instructs the regex engine to only compare base characters, and ignore additional marks such as combining accents:
  
  ```raku
  say so 'a' ~~ rx/ä/;                # OUTPUT: «False␤»
  say so 'a' ~~ rx:ignoremark /ä/;    # OUTPUT: «True␤»
  say so 'ỡ' ~~ rx:ignoremark /o/;    # OUTPUT: «True␤»
  
  ```
  
  ### [Ratchet](#Regexes "go to top of document")[§](#Ratchet "direct link")
  
  The `:ratchet` or `:r` adverb causes the regex engine to not backtrack (see [backtracking](/language/regexes#Backtracking)). Mnemonic: a [ratchet](https://en.wikipedia.org/wiki/Ratchet_%28device%29) only moves in one direction and can't backtrack.
  
  Without this adverb, parts of a regex will try different ways to match a string in order to make it possible for other parts of the regex to match. For example, in `'abc' ~~ /\w+ ./`, the `\w+` first eats up the whole string, `abc` but then the `.` fails. Thus `\w+` gives up a character, matching only `ab`, and the `.` can successfully match the string `c`. This process of giving up characters (or in the case of alternations, trying a different branch) is known as backtracking.
  
  ```raku
  say so 'abc' ~~ / \w+ . /;        # OUTPUT: «True␤»
  say so 'abc' ~~ / :r \w+ . /;     # OUTPUT: «False␤»
  ```
  
  Ratcheting can be an optimization, because backtracking is costly. But more importantly, it closely corresponds to how humans parse a text. If you have a regex `my regex identifier { \w+ }` and `my regex keyword { if | else | endif }`, you intuitively expect the `identifier` to gobble up a whole word and not have it give up its end to the next rule, if the next rule otherwise fails.
  
  For example, you don't expect the word `motif` to be parsed as the identifier `mot` followed by the keyword `if`. Instead, you expect `motif` to be parsed as one identifier; and if the parser expects an `if` afterwards, best that it should fail than have it parse the input in a way you don't expect.
  
  Since ratcheting behavior is often desirable in parsers, there's a shortcut to declaring a ratcheting regex:
  
  ```raku
  my token thing { ... };
  # short for
  my regex thing { :r ... };
  
  ```
  
  ### [Sigspace](#Regexes "go to top of document")[§](#Sigspace "direct link")
  
  The **`:sigspace`** or **`:s`** adverb changes the behavior of unquoted whitespace in a regex.
  
  Without `:sigspace`, unquoted whitespace in a regex is generally ignored, to make regexes more readable by programmers. When `:sigspace` is present, unquoted whitespace may be converted into `<.ws>` subrule calls depending on where it occurs in the regex.
  
  ```raku
  say so "I used Photoshop®"   ~~ m:i/   photo shop /;  # OUTPUT: «True␤»
  say so "I used a photo shop" ~~ m:i:s/ photo shop /;  # OUTPUT: «True␤»
  say so "I used Photoshop®"   ~~ m:i:s/ photo shop /;  # OUTPUT: «False␤»
  
  ```
  
  `m:s/ photo shop /` acts the same as `m/ photo <.ws> shop <.ws> /`. By default, `<.ws>` makes sure that words are separated, so `a b` and `^&` will match `<.ws>` in the middle, but `ab` won't:
  
  ```raku
  say so "ab" ~~ m:s/a <.ws> b/;     # OUTPUT: «False␤»
  say so "a b" ~~ m:s/a <.ws> b/;    # OUTPUT: «True␤»
  say so "^&" ~~ m:s/'^' <.ws> '&'/; # OUTPUT: «True␤»
  
  ```
  
  The third line is matched, because `^&` is not a word. For more clarification on how `<.ws>` rule works, refer to [WS rule description](/language/grammars#ws).
  
  Where whitespace in a regex turns into `<.ws>` depends on what comes before the whitespace. In the above example, whitespace in the beginning of a regex doesn't turn into `<.ws>`, but whitespace after characters does. In general, the rule is that if a term might match something, whitespace after it will turn into `<.ws>`.
  
  In addition, if whitespace comes after a term but *before* a quantifier (`+`, `*`, or `?`), `<.ws>` will be matched after every match of the term. So, `foo +` becomes `[ foo <.ws> ]+`. On the other hand, whitespace *after* a quantifier acts as normal significant whitespace; e.g., "`foo+` " becomes `foo+ <.ws>`. On the other hand, whitespace between a quantifier and the `%` or `%%` quantifier modifier is not significant. Thus `foo+ % ,` does *not* become `foo+ <.ws>% ,` (which would be invalid anyway); instead, neither of the spaces are significant.
  
  In all, this code:
  
  ```raku
  rx :s {
      ^^
      {
          say "No sigspace after this";
      }
      <.assertion_and_then_ws>
      characters_with_ws_after+
      ws_separated_characters *
      [
      | some "stuff" .. .
      | $$
      ]
      :my $foo = "no ws after this";
      $foo
  }
  
  ```
  
  Becomes:
  
  ```raku
  rx {
      ^^ <.ws>
      {
          say "No space after this";
      }
      <.assertion_and_then_ws> <.ws>
      characters_with_ws_after+ <.ws>
      [ws_separated_characters <.ws>]* <.ws>
      [
      | some <.ws> "stuff" <.ws> .. <.ws> . <.ws>
      | $$ <.ws>
      ] <.ws>
      :my $foo = "no ws after this";
      $foo <.ws>
  }
  
  ```
  
  If a regex is declared with the `rule` keyword, both the `:sigspace` and `:ratchet` adverbs are implied.
  
  Grammars provide an easy way to override what `<.ws>` matches:
  
  ```raku
  grammar Demo {
      token ws {
          <!ww>       # only match when not within a word
          \h*         # only match horizontal whitespace
      }
      rule TOP {      # called by Demo.parse;
          a b '.'
      }
  }
  
  # doesn't parse, whitespace required between a and b
  say so Demo.parse("ab.");                 # OUTPUT: «False␤»
  say so Demo.parse("a b.");                # OUTPUT: «True␤»
  say so Demo.parse("a\tb .");              # OUTPUT: «True␤»
  
  # \n is vertical whitespace, so no match
  say so Demo.parse("a\tb\n.");             # OUTPUT: «False␤»
  ```
  
  When parsing file formats where some whitespace (for example, vertical whitespace) is significant, it's advisable to override `ws`.
  
  ### [Perl compatibility adverb](#Regexes "go to top of document")[§](#Perl_compatibility_adverb "direct link")
  
  The **`:Perl5`** or **`:P5`** adverb switch the Regex parsing and matching to the way Perl regexes behave:
  
  ```raku
  so 'hello world' ~~ m:Perl5/^hello (world)/;   # OUTPUT: «True␤»
  so 'hello world' ~~ m/^hello (world)/;         # OUTPUT: «False␤»
  so 'hello world' ~~ m/^ 'hello ' ('world')/;   # OUTPUT: «True␤»
  ```
  
  The regular behavior is recommended and more idiomatic in Raku of course, but the **`:Perl5`** adverb can be useful when compatibility with Perl is required.
  
  ## [Matching adverbs](#Regexes "go to top of document")[§](#Matching_adverbs "direct link")
  
  In contrast to regex adverbs, which are tied to the declaration of a regex, matching adverbs only make sense when matching a string against a regex.
  
  They can never appear inside a regex, only on the outside – either as part of an `m/.../` match or as arguments to a match method.
  
  ### [Positional adverbs](#Regexes "go to top of document")[§](#Positional_adverbs "direct link")
  
  Positional adverbs make the expression match only the string in the indicated position:
  
  ```raku
  my $data = "f fo foo fooo foooo fooooo foooooo";
  say $data ~~ m:nth(4)/fo+/;   # OUTPUT: «｢foooo｣␤»
  say $data ~~ m:1st/fo+/;      # OUTPUT: «｢fo｣␤»
  say $data ~~ m:3rd/fo+/;      # OUTPUT: «｢fooo｣␤»
  say $data ~~ m:nth(1,3)/fo+/; # OUTPUT: «(｢fo｣ ｢fooo｣)␤»
  ```
  
  As you can see, the adverb argument can also be a list. There's actually no difference between the `:nth` adverb and the rest. You choose them only based on legibility. From 6.d, you can also use [`Junction`](/type/Junction)s, [`Seq`](/type/Seq)s and [`Range`](/type/Range)s, even infinite ones, as arguments.
  
  ```raku
  my $data = "f fo foo fooo foooo fooooo foooooo";
  say $data ~~ m:st(1|8)/fo+/;  # OUTPUT: «True␤»
  ```
  
  In this case, one of them exists (1), so it returns True. Observe that we have used `:st`. As said above, it's functionally equivalent, although obviously less legible than using `:nth`, so this last form is advised.
  
  ### [Counting](#Regexes "go to top of document")[§](#Counting "direct link")
  
  The `:x` counting adverb makes the expression match many times, like the `:g` adverb, but only up to the limit given by the adverb expression, stopping once the specified number of matches has been reached. The value must be a [`Numeric`](/type/Numeric) or a [`Range`](/type/Range).
  
  ```raku
  my $data = "f fo foo fooo foooo fooooo foooooo";
  $data ~~ s:x(8)/o/X/; # f fX fXX fXXX fXXoo fooooo foooooo
  ```
  
  ### [Continue](#Regexes "go to top of document")[§](#Continue "direct link")
  
  The `:continue` or short `:c` adverb takes an argument. The argument is the position where the regex should start to search. By default, it searches from the start of the string, but `:c` overrides that. If no position is specified for `:c`, it will default to `0` unless `$/` is set, in which case, it defaults to `$/.to`.
  
  ```raku
  given 'a1xa2' {
      say ~m/a./;         # OUTPUT: «a1␤»
      say ~m:c(2)/a./;    # OUTPUT: «a2␤»
  }
  ```
  
  *Note:* unlike `:pos`, a match with :continue() will attempt to match further in the string, instead of failing:
  
  ```raku
  say "abcdefg" ~~ m:c(3)/e.+/; # OUTPUT: «｢efg｣␤»
  say "abcdefg" ~~ m:p(3)/e.+/; # OUTPUT: «False␤»
  ```
  
  ### [Exhaustive](#Regexes "go to top of document")[§](#Exhaustive "direct link")
  
  To find all possible matches of a regex – including overlapping ones – and several ones that start at the same position, use the `:exhaustive` (short `:ex`) adverb.
  
  ```raku
  given 'abracadabra' {
      for m:exhaustive/ a .* a / -> $match {
          say ' ' x $match.from, ~$match;
      }
  }
  ```
  
  The above code produces this output:
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
      abracadabra
      abracada
      abraca
      abra
         acadabra
         acada
         aca
           adabra
           ada
             abra
  
  
  ```
  
  
  ```
  
  ### [Global](#Regexes "go to top of document")[§](#Global "direct link")
  
  Instead of searching for just one match and returning a [`Match`](/type/Match), search for every non-overlapping match and return them in a [`List`](/type/List). In order to do this, use the `:global` adverb:
  
  ```raku
  given 'several words here' {
      my @matches = m:global/\w+/;
      say @matches.elems;         # OUTPUT: «3␤»
      say ~@matches[2];           # OUTPUT: «here␤»
  }
  ```
  
  `:g` is shorthand for `:global`.
  
  ### [Pos](#Regexes "go to top of document")[§](#Pos "direct link")
  
  Anchor the match at a specific position in the string:
  
  ```raku
  given 'abcdef' {
      my $match = m:pos(2)/.*/;
      say $match.from;        # OUTPUT: «2␤»
      say ~$match;            # OUTPUT: «cdef␤»
  }
  ```
  
  `:p` is shorthand for `:pos`.
  
  *Note:* unlike `:continue`, a match anchored with :pos() will fail, instead of attempting to match further down the string:
  
  ```raku
  say "abcdefg" ~~ m:c(3)/e.+/; # OUTPUT: «｢efg｣␤»
  say "abcdefg" ~~ m:p(3)/e.+/; # OUTPUT: «False␤»
  ```
  
  ### [Overlap](#Regexes "go to top of document")[§](#Overlap "direct link")
  
  To get several matches, including overlapping matches, but only one (the longest) from each starting position, specify the `:overlap` (short `:ov`) adverb:
  
  ```raku
  given 'abracadabra' {
      for m:overlap/ a .* a / -> $match {
          say ' ' x $match.from, ~$match;
      }
  }
  ```
  
  produces
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
      abracadabra
         acadabra
           adabra
             abra
  
  
  ```
  
  
  ```
  
  ## [Substitution adverbs](#Regexes "go to top of document")[§](#Substitution_adverbs "direct link")
  
  You can apply matching adverbs (such as `:global`, `:pos` etc.) to substitutions. In addition, there are adverbs that only make sense for substitutions, because they transfer a property from the matched string to the replacement string.
  
  ### [Samecase](#Regexes "go to top of document")[§](#Samecase "direct link")
  
  The `:samecase` or `:ii` substitution adverb implies the `:ignorecase` adverb for the regex part of the substitution, and in addition carries the case information to the replacement string:
  
  ```raku
  $_ = 'The cat chases the dog';
  s:global:samecase[the] = 'a';
  say $_;                 # OUTPUT: «A cat chases a dog␤»
  
  ```
  
  Here you can see that the first replacement string `a` got capitalized, because the first string of the matched string was also a capital letter.
  
  ### [Samemark](#Regexes "go to top of document")[§](#Samemark "direct link")
  
  The `:samemark` or `:mm` adverb implies `:ignoremark` for the regex, and in addition, copies the markings from the matched characters to the replacement string:
  
  ```raku
  given 'äộñ' {
      say S:mm/ a .+ /uia/;           # OUTPUT: «üị̂ã␤»
  }
  
  ```
  
  ### [Samespace](#Regexes "go to top of document")[§](#Samespace "direct link")
  
  The `:samespace` or `:ss` substitution modifier implies the `:sigspace` modifier for the regex, and in addition, copies the whitespace from the matched string to the replacement string:
  
  ```raku
  say S:samespace/a ./c d/.raku given "a b";      # OUTPUT: «"c d"␤»
  say S:samespace/a ./c d/.raku given "a\tb";     # OUTPUT: «"c\td"␤»
  say S:samespace/a ./c d/.raku given "a\nb";     # OUTPUT: «"c\nd"␤»
  
  ```
  
  The `ss/.../.../` syntactic form is a shorthand for `s:samespace/.../.../`.
  
  # [Backtracking](#Regexes "go to top of document")[§](#Backtracking "direct link")
  
  Raku defaults to [backtracking](/language/glossary#Backtracking) when evaluating regular expressions. Backtracking is a technique that allows the engine to try different matching in order to allow every part of a regular expression to succeed. This is costly, because it requires the engine to usually eat up as much as possible in the first match and then adjust going backwards in order to ensure all regular expression parts have a chance to match.
  
  ## [Understanding backtracking](#Regexes "go to top of document")[§](#Understanding_backtracking "direct link")
  
  In order to better understand backtracking, consider the following example:
  
  ```raku
  my $string = 'PostgreSQL is a SQL database!';
  say $string ~~ /(.+)(SQL) (.+) $1/; # OUTPUT: «｢PostgreSQL is a SQL｣␤»
  
  ```
  
  What happens in the above example is that the string has to be matched against the second occurrence of the word *SQL*, eating all characters before and leaving out the rest.
  
  Since it is possible to execute a piece of code within a regular expression, it is also possible to inspect the [`Match`](/type/Match) object within the regular expression itself:
  
  ```raku
  my $iteration = 0;
  sub show-captures( Match $m ){
      my Str $result_split;
      say "\n=== Iteration {++$iteration} ===";
      for $m.list.kv -> $i, $capture {
          say "Capture $i = $capture";
          $result_split ~= '[' ~ $capture ~ ']';
      }
  
      say $result_split;
  }
  
  $string ~~ /(.+)(SQL) (.+) $1 .+ { show-captures( $/ );  }/;
  
  ```
  
  The `show-captures` method will dump all the elements of `$/` producing the following output:
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
  === Iteration 1 ===
  Capture 0 = Postgre
  Capture 1 = SQL
  Capture 2 =  is a
  [Postgre][SQL][ is a ]
  
  
  ```
  
  
  ```
  
  showing that the string has been split around the second occurrence of *SQL*, that is the repetition of the first capture (`$/[1]`).
  
  With that in place, it is now possible to see how the engine backtracks to find the above match: it does suffice to move the `show-captures` in the middle of the regular expression, in particular before the repetition of the first capture `$1` to see it in action:
  
  ```raku
  my $iteration = 0;
  sub show-captures( Match $m ){
      my Str $result-split;
      say "\n=== Iteration {++$iteration} ===";
      for $m.list.kv -> $i, $capture {
          say "Capture $i = $capture";
          $result-split ~= '[' ~ $capture ~ ']';
      }
  
      say $result-split;
  }
  
  $string ~~ / (.+)(SQL) (.+) { show-captures( $/ );  } $1 /;
  
  ```
  
  The output will be much more verbose and will show several iterations, with the last one being the *winning*. The following is an excerpt of the output:
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
  === Iteration 1 ===
  Capture 0 = PostgreSQL is a
  Capture 1 = SQL
  Capture 2 =  database!
  [PostgreSQL is a ][SQL][ database!]
  
  === Iteration 2 ===
  Capture 0 = PostgreSQL is a
  Capture 1 = SQL
  Capture 2 =  database
  [PostgreSQL is a ][SQL][ database]
  
  ...
  
  === Iteration 24 ===
  Capture 0 = Postgre
  Capture 1 = SQL
  Capture 2 =  is a
  [Postgre][SQL][ is a ]
  
  
  ```
  
  
  ```
  
  In the first iteration the *SQL* part of *PostgreSQL* is kept within the word: that is not what the regular expression asks for, so there's the need for another iteration. The second iteration will move back, in particular one character back (removing thus the final *!*) and try to match again, resulting in a fail since again the *SQL* is still kept within *PostgreSQL*. After several iterations, the final result is match.
  
  It is worth noting that the final iteration is number *24*, and that such number is exactly the distance, in number of chars, from the end of the string to the first *SQL* occurrence:
  
  ```raku
  say $string.chars - $string.index: 'SQL'; # OUTPUT: «23␤»
  
  ```
  
  Since there are 23 chars from the very end of the string to the very first *S* of *SQL* the backtracking engine will need 23 "useless" matches to find the right one, that is, it will need 24 steps to get the final result.
  
  Backtracking is a costly machinery, therefore it is possible to disable it in those cases where the matching can be found *forward* only.
  
  With regards to the above example, disabling backtracking means the regular expression will not have any chance to match:
  
  ```raku
  say $string ~~ /(.+)(SQL) (.+) $1/;      # OUTPUT: «｢PostgreSQL is a SQL｣␤»
  say $string ~~ / :r (.+)(SQL) (.+) $1/;  # OUTPUT: «Nil␤»
  
  ```
  
  The fact is that, as shown in the *iteration 1* output, the first match of the regular expression engine will be `PostgreSQL is a` , `SQL`, `database` that does not leave out any room for matching another occurrence of the word *SQL* (as `$1` in the regular expression). Since the engine is not able to get backward and change the path to match, the regular expression fails.
  
  It is worth noting that disabling backtracking will not prevent the engine to try several ways to match the regular expression. Consider the following slightly changed example:
  
  ```raku
  my $string = 'PostgreSQL is a SQL database!';
  say $string ~~ / (SQL) (.+) $1 /; # OUTPUT: «Nil␤»
  
  ```
  
  Since there is no specification for a character before the word *SQL*, the engine will match against the rightmost word *SQL* and go forward from there. Since there is no repetition of *SQL* remaining, the match fails. It is possible, again, to inspect what the engine performs introducing a dumping piece of code within the regular expression:
  
  ```raku
  my $iteration = 0;
  sub show-captures( Match $m ){
      my Str $result-split;
      say "\n=== Iteration {++$iteration} ===";
      for $m.list.kv -> $i, $capture {
          say "Capture $i = $capture";
          $result-split ~= '[' ~ $capture ~ ']';
      }
  
      say $result-split;
  }
  
  $string ~~ / (SQL) (.+) { show-captures( $/ ); } $1 /;
  
  ```
  
  that produces a rather simple output:
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
  === Iteration 1 ===
  Capture 0 = SQL
  Capture 1 =  is a SQL database!
  [SQL][ is a SQL database!]
  
  === Iteration 2 ===
  Capture 0 = SQL
  Capture 1 =  database!
  [SQL][ database!]
  
  
  ```
  
  
  ```
  
  Even using the [:r](/language/regexes#Ratchet) adverb to prevent backtracking will not change things:
  
  ```raku
  my $iteration = 0;
  sub show-captures( Match $m ){
      my Str $result-split;
      say "\n=== Iteration {++$iteration} ===";
      for $m.list.kv -> $i, $capture {
          say "Capture $i = $capture";
          $result-split ~= '[' ~ $capture ~ ']';
      }
  
      say $result-split;
  }
  
  $string ~~ / :r (SQL) (.+) { show-captures( $/ ); } $1 /;
  
  ```
  
  and the output will remain the same:
  
  ｢text｣ without highlighting
  
  ```
  
  
  ```
  
  === Iteration 1 ===
  Capture 0 = SQL
  Capture 1 =  is a SQL database!
  [SQL][ is a SQL database!]
  
  === Iteration 2 ===
  Capture 0 = SQL
  Capture 1 =  database!
  [SQL][ database!]
  
  
  ```
  
  
  ```
  
  This demonstrates that disabling backtracking does not mean disabling possible multiple iterations of the matching engine, but rather disabling the backward matching tuning.
  
  ## [Backtracking control](#Regexes "go to top of document")[§](#Backtracking_control "direct link")
  
  Raku offers several tools for controlling backtracking. First, you can use the `:ratchet` regex adverb to turn ratcheting on (or `:!ratchet` to turn it off). See [backtracking](/language/regexes#Ratchet) for details. Note that, as with all regex adverbs, you can limit the scope of `:ratchet` using square brackets. Thus, in the following code, backtracking is enabled for the first quantifier (`\S+`), disabled for the second quantifier (`\s+`), and re-enabled for the third (`\d+`).
  
  ```raku
  'A  42' ~~  rx/\S+ [:r \s+ [:!r \d+ ] ] . /  # OUTPUT: «｢A  42｣␤»
  
  ```
  
  `:ratchet` is enabled by default in `token`s and `rule`s; see [grammars](/language/grammars) for more details.
  
  Raku also offers three regex metacharacters to control backtracking at for an individual atom.
  
  ### [Disable backtracking: `:`](#Regexes "go to top of document")[§](#Disable_backtracking:_: "direct link")
  
  The `:` metacharacter disables backtracking for the previous atom. Thus, `/ .*: a/` does not match `" a"` because the `.*` matches the entire string, leaving nothing for the `a` to match without backtracking.
  
  ### [Enable greedy backtracking: `:!`](#Regexes "go to top of document")[§](#Enable_greedy_backtracking:_:! "direct link")
  
  The `:!` metacharacter enables greedy backtracking for the previous atom – that is, provides the backtracking behavior that's used when `:ratchet` is not in effect. `:!` is closely related to the `!` [greedy quantifier modifier](/language/regexes#Greedy_versus_frugal_quantifiers:_?); however – unlike `!`, which can only be used after a quantifier – `:!` can be used after any atom. For example, `:!` can be used after an alternation:
  
  ```raku
  'abcd' ~~ /:ratchet [ab | abc]   cd/;  # OUTPUT: «Nil␤»
  'abcd' ~~