Überarbeitungsverlauf[Zurück]
Klicke auf Einblenden/Ausblenden von Überarbeitungen 2
korrigiere Tippfehler

14 Apr '20, 13:17

Cletus's gravatar image

Cletus
1.6k75866

Token-Vergleich mit expl3

Das folgende Codebeispiel zeigt zwei Vergleiche mit unterschiedlichem Ergebnis. \documentclass{article} \usepackage{expl3} \begin{document} Vergleich mit plain-\TeX: \ifx{\ss}\ss gleich\else ungleich\fi Vergleich mit expl3: \ExplSyntaxOn \token_if_eq_meaning:NNTF {\ss} \ss {gleich} {ungleich} \ExplSyntaxOff \end{document} Der erste Vergleich ergibt „ungleich“. Dies entspricht meiner Erwartung, da ich davon ausgehe, dass hier nicht `{\ss}` und `\ss` miteinander verglichen werden, sondern `{` und `\ss`, da dies die ersten beiden Token nach `\ifx` sind. Der zweite Vergleich ergibt „gleich“. Dies scheint zwar semantisch sinnvoll, ist aber überraschend, denn erstens ist `\token_if_eq_meaning:NNTF` mit Hilfe von `\ifx` definiert, wie man dem Dokument source3 entnehmen kann, sollte sich also genauso verhalten. Zweitens verbietet den die expl3-Anleitung die Verwendung geschweifter Klammern für `N`-Argumente. Wieso ergeben beide Vergleiche unterschiedliche Ergebnisse? Ich komme aus folgendem Grund auf die Frage: Eine Funktion mit N-Argument könnte missbräuchlich mit einem Argument in geschweiften Klammern aufgerufen werden. Dann würde aber der `\token_if_eq_meaning:NNTF`-Befehl, der innerhalb dieser Funktion auftritt durcheinander kommen. \documentclass{article} \usepackage{expl3} \begin{document} \ExplSyntaxOn \cs_new:Npn \meinbefehl:N #1 { \token_if_eq_meaning:NNTF #1 \ss {Eszett~gelesen} {kein~Eszett~gelesen} } \meinbefehl:N a \par \meinbefehl:N \ss \par \meinbefehl:N {ab} \ExplSyntaxOff \end{document} Der dritte Aufruf von `\meinbefehl:N` ergibt „Eszett gelesenkein Eszett gelesen“. Hier wird offenbar nicht `ab` mit `\ss` verglichen, sondern `a` mit `b`, sodass der True-Code zum False-Code wird und der False-Code nicht mehr als Befehlsargument aufgefasst wird und somit einfach angehängt wird. Ich habe mich nun gefragt, ob es sinnvoll wäre, dass das unerwünschte Verhalten durch geschweifte Klammern auszuschließen: \token_if_eq_meaning:NNTF {#1} \ss {Eszett~gelesen} {kein~Eszett~gelesen} Das scheint zu funktionieren, die Frage ist nur, ob man sich darauf verlassen kann.
Klicke auf Einblenden/Ausblenden von Überarbeitungen 1

14 Apr '20, 13:14

Cletus's gravatar image

Cletus
1.6k75866

Token-Vergleich mit expl3

Das folgende Codebeispiel zeigt zwei Vergleiche mit unterschiedlichem Ergebnis. \documentclass{article} \usepackage{expl3} \begin{document} Vergleich mit plain-\TeX: \ifx{\ss}\ss gleich\else ungleich\fi Vergleich mit expl3: \ExplSyntaxOn \token_if_eq_meaning:NNTF {\ss} \ss {gleich} {ungleich} \ExplSyntaxOff \end{document} Der erste Vergleich ergibt „ungleich“. Dies entspricht meiner Erwartung, da ich davon ausgehe, dass hier nicht `{\ss}` und `\ss` miteinander verglichen werden, sondern `{` und `\ss`, da dies die ersten beiden Token nach `\ifx` sind. Der zweite Vergleich ergibt „gleich“. Dies scheint zwar semantisch sinnvoll, ist aber überraschend, denn erstens ist `\token_if_eq_meaning:NNTF` mit Hilfe von `\ifx` definiert, wie man dem Dokument source3 entnehmen kann, sollte sich also genauso verhalten. Zweitens verbietet den expl3-Anleitung die Verwendung geschweifter Klammern für `N`-Argumente. Wieso ergeben beide Vergleiche unterschiedliche Ergebnisse? Ich komme aus folgendem Grund auf die Frage: Eine Funktion mit N-Argument könnte missbräuchlich mit einem Argument in geschweiften Klammern aufgerufen werden. Dann würde aber der `\token_if_eq_meaning:NNTF`-Befehl, der innerhalb dieser Funktion auftritt durcheinander kommen. \documentclass{article} \usepackage{expl3} \begin{document} \ExplSyntaxOn \cs_new:Npn \meinbefehl:N #1 { \token_if_eq_meaning:NNTF #1 \ss {Eszett~gelesen} {kein~Eszett~gelesen} } \meinbefehl:N a \par \meinbefehl:N \ss \par \meinbefehl:N {ab} \ExplSyntaxOff \end{document} Der dritte Aufruf von `\meinbefehl:N` ergibt „Eszett gelesenkein Eszett gelesen“. Hier wird offenbar nicht `ab` mit `\ss` verglichen, sondern `a` mit `b`, sodass der True-Code zum False-Code wird und der False-Code nicht mehr als Befehlsargument aufgefasst wird und somit einfach angehängt wird. Ich habe mich nun gefragt, ob es sinnvoll wäre, dass unerwünschte Verhalten durch geschweifte Klammern auszuschließen: \token_if_eq_meaning:NNTF {#1} \ss {Eszett~gelesen} {kein~Eszett~gelesen} Das scheint zu funktionieren, die Frage ist nur, ob man sich darauf verlassen kann.