Es gibt viele Funktionen, die von der Programmierumgebung expl3 bereitgestellt werden und die in interface3.pdf mit einem schwarzen Sternchen (vollständig erweiterbar) oder einem weißen Sternchen (eingeschränkt erweiterbar) gekennzeichnet sind.
Warum sind so viele Funktionen als vollständig erweiterbar gekennzeichnet, ohne offizielle Informationen über die Anzahl der Erweiterungen bereitzustellen, die zum Erreichen des Ergebnisses erforderlich sind?
Nun, bei einigen vollständig erweiterbaren Endrekursionsdingen, bei denen in der Implementierung keine Mittel zur Erweiterungssteuerung wie \exp:w/ \exp_end:angewendet werden, hängen sowohl die Anzahl der Rekursionen als auch die Anzahl der Erweiterungen, die zum Erreichen des Ergebnisses erforderlich sind, von den von den Benutzern bereitgestellten Argumenten ab. Daher können dort keine genauen Informationen über die Anzahl der Erweiterungen bereitgestellt werden, die zum Erreichen des Ergebnisses erforderlich sind.
Es gibt jedoch viele Funktionen, bei denen dies nicht der Fall ist und bei denen genaue Informationen über die Anzahl der Erweiterungen bereitgestellt werden könnten, die zum Erreichen des Ergebnisses erforderlich sind.
Wie kann man bei solchen vollständig erweiterbaren expl3-Funktionen in Erweiterungskontexten mit Sicherheit wissen, wann das Ergebnis vorliegt?
Ich möchte beispielsweise wissen, wie viele Erweiterungen ausgelöst werden müssen, um das Ergebnis von zu erhalten \str_tail:n.
In Erweiterungskontexten können Sie x-expansion nicht verwenden, da dies selbst nicht erweiterbar ist.
Sie können -expansion nicht einfach verwenden f, da dies möglicherweise ein weiteres führendes Leerzeichen aus der Zeichenfolge entfernt.
Wenn die betreffende vollständig erweiterbare Funktion nicht vorhanden war, \str_tail:nsondern etwas, bei dem die Argumente selbst keine Zeichenfolgen nicht erweiterbarer expliziter Zeichentoken sind, ekann -expansion mehr Erweiterungen auslösen als gewünscht. Abgesehen davon ist -expansion bei Engines, bei denen das \expanded-Primitiv nicht verfügbar ist, eteuer.
In diesem Fall \str_tail:nkönnte man auf die Idee kommen, sich source3.pdf anzuschauen und festzustellen, dass bei der aktuellen Implementierung vier Erweiterungen nötig sind:
\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 }
Erweiterung 1 liefert Ihnen den Ersatztext von \str_tail:n.
Erweiterung 2 führt das \exp_after:wN-Ding aus, das endet, wenn das Ergebnis des \if_charcode:w-Tests ausgewertet ist und hierbei wird das erste Token der Zeichenfolge als Argument zum Vergleichen seines Kategoriecodes mit dem Kategoriecode von verwendet \scan_stop:.
Erweiterung 3 erweitert , \__str_tail_auxi:wwas \fi:zum Abgleichen vorangestellt wird \if_charcode:wund das durch Kategorie-11- X-getrennte Argument beibehält und das \s__str_stopdurch -getrennte Argument entfernt.
Erweiterung 4 entfernt \fi:.
Durch einen Blick in source3.pdf erhalten Sie jedoch keine Informationen über offizielle Details der Implementierung.
Falls sich die interne Implementierung ändert, \str_tail:nkann sich auch die Anzahl der Erweiterungen ändern, die zum Erhalten des Ergebnisses erforderlich sind.
Ich sehe keine allgemeine Methode mit einer vollständig erweiterbaren Funktion, um sicherzustellen, dass Sie den richtigen Moment erhalten, um die Token, die das Ergebnis dieser Funktion bilden, mit einigen anderen Token zu umgeben, außer zu wissen, nach wie vielen Erweiterungen das Ergebnis der Funktion vorliegt.
Wenn Sie \exp:wdie Erweiterung einer vollständig erweiterbaren Funktion auslösen, die von der Programmierumgebung expl3 bereitgestellt wird, bis das Ergebnis dieser Funktion vorliegt, sehe ich keine allgemeine Methode, um sicherzustellen, dass dies \exp_end:zum richtigen Zeitpunkt zum Stoppen \exp:wder Erweiterung ausgeführt wird, die ohne die Kenntnis der Anzahl der Erweiterungen auskommt, nach denen das Ergebnis dieser Funktion vorliegt.
Daher denke ich, dass diese Information bei vollständig erweiterbaren Funktionen als offizielle Information bereitgestellt werden sollte.
Wie viele Erweiterungen sind bis zum Ergebnis von Funktionen nötig \exp_args:...oder \use_i:nngibt es welche?
Diese Information wird in interface3.pdf nicht offiziell bereitgestellt.
Kann ich mich beispielsweise darauf verlassen, dass \use_i:nnimmer genau eine Erweiterung erforderlich ist, ohne dass jemand meckert, weil ich Informationen aus internen Implementierungsdetails ableite, anstatt mich nur auf Fakten zu verlassen, die offiziell dokumentiert sind?
Was sollte mich dazu veranlassen, mich auf Konsistenz zwischen expl3-Releases in Aspekten zu verlassen, die nicht offiziell dokumentiert sind?
(Die LaTeX-Distribution, die mit meiner Linux-Distribution mitgeliefert wird, unterscheidet sich so sehr von TeX Live 2024...)
Antwort1
Die Dokumentation ist beabsichtigt. Es gibt nur sehr wenige (untergeordnete) Funktionen, bei denen die Anzahl der Erweiterungen wichtig ist und bei denen das Team oder andere sie kennen/sich darauf verlassen müssen: Diese sind dokumentiert. In anderen Fällen ist die Verwendung der Erweiterung e- oder f-type normalerweise ausreichend. Zum Beispiel:\str_tail:n Notwendigerzeugt einen String - dies ist daher in einem e-Typ-Kontext sicher, es gibt alsokeine Notwendigkeitum zu dokumentieren, wie viele Erweiterungen erforderlich sind.
Allgemeiner gesagt, wenn eine FunktiondokumentierenTokens können Sie edie -Typ-Erweiterung nicht verwenden, bleiben aber im Allgemeinen bei, \protected@edefda dies mit robusten LaTeX2e-Befehlen funktioniert – expl3tut dies im Allgemeinen nicht. Für reinen Text \text_expand:ntut es etwas Ähnliches wie, \protected@edeffunktioniert aber nicht gut mit nicht-textueller Erweiterung. So oder so ermöglichen diese Ansätze die Erweiterung von expl3Funktionen, während das fragile LaTeX2e-Material (eg \textbfoder ähnliches) erhalten bleibt.
Die Dokumentation der Anzahl der erforderlichen Erweiterungen schränkt alle Codeänderungen ein: Soweit möglich tun wir dies nicht – die Einschränkungen beziehen sich nur auf diejenigen, die Teil der API sind. Wenn Sie einen klaren Anwendungsfall haben, der eine solche API-Stabilität zu erfordern scheint, melden Sie ein Problem und fordern Sie eine (Dokumentations-)Änderung an.