_NAME, _CALL, _GOTO (and/or: _DEF, _USE, ...)

[xparq]

Well, to avoid the brittle address-tracking horror of #16, a named rule can't pre-register it's this address at construction time, where things are in flux.

At runtime, though:

• the first time the engine sees a name, it can safely remember its address. (Well, its parent's address, technically, as a _NAME opcode "rule" is always in the PROD of some owner rule -- the real one that the name belongs to.)

  • Well, not really: rules can be copied/created even run-time, so those addresses must be updated then, too! :-/
    • Short of that, only fresh new full searches can provide a reliable association!
      _DEF "name" and _USE "name" have now been implemented, doing just that (72e4508).

• or, if the first time it sees a branch OP (or other reference to a name), and it can't find it in the name->rule lookup table, it does a full search and updates the table. (Or errs out.)

• This would also require a preprocessing/compilation stage over the grammar. (It's fully interpreted yet.) -> Grammar preprocessing/compilation phase (after construction, before parsing) #31

  • Which would also imply that a (re)compilation would also be needed for every single run-time change to the grammar!

---

• Make a distinction between NAME and LABEL!... Name should really just be the name of a rule... err... but should it also be an ID then?... And LABEL is really any branching (GOTO/CALL) destination... Branching can apply to both names and labels, but not all labels are names! Labels should probably be more indirect, and also support positions (slots) as branching targets, where the actual rule can get replaced by another (independent of those rules' own name/identity)!

  So, labels are a subset of names. Every name can be used as a label, but labels can't always be used as names.