Backreferences...

[xparq]

• Named captures like SAVE "name" are there already (Add _SAVE & _SAVE_AS for unnamed/named captures #4), so all it takes is an operator like USE "name" -- which is also there already (_NAME, _CALL, _GOTO (and/or: _DEF, _USE, ...) #15)...

It's just that SAVE and DEF (which USE is the counterpart of, currently) use different namespaces.

• How to properly address the addressing bit of the operations?... With addressing bits, literally? Or should it be part of the operand? "name" itself should tell where to look for the item, like URLs?
  • OK, do it with the name; see below... (Leaving the addressing part for now, TBD after Grammar preprocessing/compilation phase (after construction, before parsing) #31!)
• It should leave the door open to further extensions. (Which really cries for the URL-like semantics...)
  • But then, if dispatching on "name": how to make it efficient? Compilation (Grammar preprocessing/compilation phase (after construction, before parsing) #31)?
    • Yes, leaving it to the name -- e.g. like "\name" or "$name", or both -- gives an instant way to make it work, and leaves the door open for a preprocessing phase to convert it to whatever it wants.
    • Well, not so fast with that "instant" solution... :-/ Actually, USE would need to know actually, if the named capture has actually matched already and it has not been backtracked, so it still has valid data! :-o So, it:
      • needs a flag that the slot has valid data ("" may not actually mean that! :-/ )
      • needs the "transactional" backtracking cleanup mechanism (which would be required for Aggregate captures with _SAVE/_SAVE_AS #10 anyway!)...
• It should be unified with the named patterns namespace, too.
  • OK, so probably a different opcode should be generated for each; seems enough to unify them for the "API", with name prefixes, and then leaving it to the preprocessor to adjust.