如何在擴展上下文中確定完全可擴展的 expl3 函數的結果何時存在?

如何在擴展上下文中確定完全可擴展的 expl3 函數的結果何時存在?

expl3程式環境提供了許多功能,在interface3.pdf中用黑色星號(完全可擴展)或白色星號(限制可擴展)標記。

為什麼這麼多函數被標記為完全可擴展,卻沒有提供有關獲得結果所需的擴展量的官方資訊?

好吧,對於一些完全可擴展的尾遞歸,在實現中沒有應用像\exp:w/這樣的擴展控製手段\exp_end:,遞歸的數量和獲得結果所需的擴展的數量都取決於用戶提供的參數。因此,那裡無法提供有關獲得結果所需的擴展量的準確資訊。

但有許多函數並非如此,並且可以提供有關獲得結果所需的擴展量的準確資訊。

有了這樣完全可擴展的 expl3 函數,如何在擴展上下文中確定結果出現的時刻?

例如,我想知道獲得 的結果需要觸發多少擴展\str_tail:n

在擴充上下文中,您不能使用x-expansion,因為它本身不可擴展。
您不能安全地僅使用f-expansion,因為這可能會從字串中刪除另一個前導空格。
如果所討論的完全可擴展函數不是\str_tail:n參數本身不是不可擴展的顯式字元標記的字串,那麼e-expansion 可能會觸發比想要的更多的擴展。除此之外,對於\expanded無法使用 - 原語的引擎,e- 擴展的成本很高。

在這種情況下,\str_tail:n可以了解 source3.pdf 並發現目前的實作需要四個擴充:

\cs_new:Npn \str_tail:n #1
  {
    \exp_after:wN \__str_tail_auxi:w
    \reverse_if:N \if_charcode:w
    \scan_stop: \tl_to_str:n {#1} X X \s__str_stop
  }
\cs_new:Npn \__str_tail_auxi:w #1 X #2 \s__str_stop { \fi: #1 }

擴充 1 為您提供 的替換文字\str_tail:n
擴充 2 執行\exp_after:wN-thingie,該 -thingie 在評估 -test 的結果時結束\if_charcode:w,因此字串的第一個標記用作參數,用於將其類別代碼與 的類別代碼進行比較\scan_stop:
擴展 3 擴展了\__str_tail_auxi:w它的前綴\fi:以進行匹配\if_charcode:w並保留類別 11-X分隔的參數並刪除\s__str_stop- 分隔的參數。
擴充 4 刪除了\fi:.

但查看 source3.pdf 並不能取得有關實施的官方細節的資訊。

如果內部實作發生變化,獲得結果所需的擴展量\str_tail:n也可能會改變。

我沒有看到具有完全可擴展函數的通用方法來確保您獲得正確的時機來用一些其他標記包圍形成該函數結果的標記,而不是知道函數結果之後的擴展量有沒有。
當用於\exp:w觸發 expl3 程式設計環境提供的完全可擴展函數的擴展直到該函數的結果出現時,我沒有看到一種通用方法來確保\exp_end:在正確的時刻執行停止\exp:w擴展,其中可以在不知道該函數的結果存在之後的擴展量的情況下進行。

所以我認為在功能完全可擴展的情況下,這些資訊應該作為官方資訊提供。

需要多少次展開才能得到函數結果\exp_args:...\use_i:nn存在?
該資訊並未在 interface3.pdf 中正式提供。
我是否可以安全地依賴,例如,\use_i:nn始終只需要一次擴展,而不會有人抱怨,因為我從內部實現細節中推斷出信息,而不是僅依賴於正式記錄的事實?
是什麼導致我在未正式記錄的方面依賴 expl3 版本之間的一致性?
(我的 Linux 發行版附帶的 LaTeX 發行版與 TeX Live 2024 有很大不同...)

答案1

文件情況是設計使然的。很少有(低級)功能的擴展數量很重要,並且團隊或其他人需要了解/依賴它:這些都被記錄下來。在其他情況下,使用e- 或f- 類型擴充通常就足夠了。例如,\str_tail:n 一定產生一個字串 - 因此這在e-type 上下文中是安全的,所以有不需要記錄需要多少次擴展。

更一般地,如果一個函數採用文件令牌,那麼你就不能使用e-type 擴展,但通常堅持使用,\protected@edef因為它與 LaTeX2e 強大的命令一起使用 -expl3通常不會這樣做。對於徹底的文本,\text_expand:n執行類似於\protected@edef非文本擴展的操作,但效果不佳。無論哪種方式,這些方法都允許擴展expl3功能,同時保留 LaTeX2e 易碎材料(例如\textbf或類似材料)。

記錄所需的擴充數量對任何程式碼變更都施加了限制:我們盡可能不這樣做 - 限制僅是那些構成 API 一部分的限制。如果您有一個明確的用例似乎需要這種 API 穩定性,請記錄問題並要求(文件)變更。

相關內容