Hi Tatsuo, Jian, Thanks, Tatsuo -- your two notes settle both open questions. Answering both inline below, with a note at the end on the follow-up work.
> Basically I think Jian's idea is good. In addition to the size reason > above, we would have less code changes when we adapt existing R020 > codes to R010. > > However it will need a wide code change as Henson said. I would like > to focus on stabilizing our code for now. Therefore I would not want > the refactoring in v48. Agreed -- out of v48, stabilize first. On R010, I'd treat it as the design lens, not the schedule: it's far out, so rather than hold RPRContext back until then, I'd do the consolidation at a sensible point after v48 but shape it against R010 (what is shared versus per-context, how the fields group), so one engine core can later back both the R020 window path and R010 without a second reshape. Not v48 -- on its own schedule once we're stable. I'll admit the R010 connection had been nagging at me for a while without a clean answer, and Jian's consolidation suggestion turns out to land right on it: framed as a size win, it's really the structural move that opens the R010 path -- that reframing is his. Which is why I'd rather shape it deliberately, as the shared engine core, than fold it in as churn. > Although I don't have any particular strong preferences, keeping > "absorption" for the runtime concept sounds good to me. Good -- "absorption" stays reserved for the runtime context-equivalence collapse, and the README explains it in one place. > For AST level name changing, "prefix/suffix merging" seems to be > already used in other areas according to Google: LLM, Linker, and > string manipulation in DNA. In the normal expression engine area, it > looks like "flattening nested quantifiers" or "quantifiers reduction" > are used for the case. So, for example, "prefix/suffix quantifiers > reduction" seems to be more appropriate? (If you don't mind it's too > long) In any case, I would like to respect your opinion. Thanks -- you're right that "merging" is well-worn elsewhere, and I'll be honest that "prefix/suffix merging" isn't a term I'd defend on the merits. Keeping it for v48 is really a stopgap to contain the ripple: the sibling Phase-1 rewrites are already named "consecutive variable / group / ALT merging", so switching to the "flattening / reduction" family would force renaming those too for consistency. So I'd treat the term itself as genuinely open -- your "flattening / reduction" neighborhood is the right one -- and converge on the established academic naming as the paper I'm preparing on the algorithm, together with a university research group, takes shape. For now I'd ship "prefix/suffix merging" only to keep the README internally consistent, and fold the settled term into the glossary pass once the paper lands on it. A doc-level name is cheap to revise later. Both of these -- the RPRContext reshape and the naming/terminology -- are "after v48, by discussion" items, and they aren't the only ones. Rather than pin down the scope of that follow-up now, I'd suggest we pick it up together once v48 is stable. Thanks again, Henson
