That's exactly it.

Now, you might wonder why I didn't add to @memoList directly. It might be best to use an example:

local $_ = 'abbbbbc';

{
   local @memoList;

   /
      a
      (?:
         (b)
         (?{ push @memoList, $1 })
       )*
      bbc
   /x;

   print(@memoList, "\n");  # bbbbb
                            # Wrong! There should only be three!
}


{
   local @memoList;

   /
      (?{ [] })
      a
      (?:
         (b)
         (?{ [ @{$^R}, $1 ] })
      )*
      bbc
      (?{ @memoList = @{$^R} })
   /x;

   print(@memoList, "\n");  # bbb
}


{
   local @temp;
   local @memoList;

   /
      # (?{ @temp = (); })  # Redundant with 'local @temp'.
      a
      (?:
         (b)
         (?{ local @temp = (@temp, $1); })
      )*
      bbc
      (?{ @memoList = @temp })
   /x;

   print(@memoList, "\n");  # bbb
}
[download]

When the regexp engine finds that it read too many 'b's — rememeber that * is greedy — it backtracks, "unreading" the last 'b' and eventually then a second last 'b'. $^R and @temp (since we keep using local to assign to @temp) are unwound when backtracking occurs, so the last assignment is undone with each "unreading". @memoList is not unwound, on the other hand, so it keeps holding the extra 'b's.

A quick tests shows that using $^R is *much* faster than using local.

Update: Removed unnecessary parens. (Copy and paste bug.)

Thank you again for elaborating on your earlier reply. I can see from your examples how localisation is necessary to avoid, for example, @memoList getting too many 'b's. There is one thing that is confusing me though. In the second and third patterns I don't understand the significance of the extra (memory group?) brackets around the code block (?{...}), as in ((?{ @memoList = @{$^R} })) and ((?{ @memoList = @temp })). Why do we need these when we are assigning within the pattern rather than having to remember outside of it? I must be missing something.

Cheers,

JohnGG

Copy and paste bug. Those parens are indeed unnecessary here.