macros

LaTeX3 erzwingt keine Argumenttypen für benutzerdefinierte Steuersequenzen,warum

Aus einer früheren Frage geht hervor:

Am gebräuchlichsten sind die Argumenttypen N und n .Ersteres bedeutet, dass das Argument ein einzelnes Token ohne Klammern sein muss , letzteres bedeutet, dass das Argument eine Liste von Tokens mit Klammern sein muss .

Dies ist mir mehr oder weniger klar,aber es sieht so aus,als ob die L3-Schnittstelle dies für benutzerdefinierte Funktionen nicht erzwingt,hier ist ein MWE:

\documentclass{article}

\begin{document}
    \ExplSyntaxOn
    \cs_new:Nn \myFunc:N {<<#1>>}
    \myFunc:N {test}
    \ExplSyntaxOff

\end{document}

Der obige Code lässt sich gut kompilieren, auch wenn ich eine geklammerte Liste von Token an die Funktion myFunc:N übergebe , die anscheinend so deklariert ist, dass sie ausschließlich ein einzelnes Token ohne Klammern akzeptiert.

Dies macht einen großen Teil der L3-Programmierschicht aus, dh Funktionsdefinitionen und Argumentspezifikationen erscheinen wie eine bloße syntaktische Konvention. seufz .

Warum werden die Argumenttypen für benutzerdefinierte Funktionen nicht erzwungen,wie man es erwarten würde?

Colons

Seltsamerweise gibt der Compiler einen Fehler aus, wenn ich den Doppelpunkt : weglasse , zum Beispiel wenn ich eine Funktion myFunc im Gegensatz zu myFunc:N deklariere . Das scheint also durchgesetzt zu werden ...



Die Programmierschicht expl3 basiert immer noch auf der TeX-Sprache und die Suche nach Argumenten erfolgt gemäß den TeX-Regeln.

Diese Regeln unterscheiden nur zwischen begrenzten und nicht begrenzten Argumenten. Und was expl3 „Funktionen“ nennt, sind eigentlich normale TeX-Makros; Variablen können je nach Typ entweder Makros oder Register sein.

Die grundlegende \cs_new:Nn - Funktion zum Definieren anderer Funktionen befasst sich nur mit nicht begrenzten Argumenten. Es braucht zwei Argumente: eines ein einzelnes Token, das ein gültiger Name für eine Funktion einschließlich der Signatur sein sollte; das zweite Argument sollte eine geklammerte Liste von Token sein.

Die Signatur wird verwendet,um den richtigen Parametertext für das zu definierende Makro zu liefern,da eine Deklaration wie

\cs_new:Nn \mymodule_foo:nn { #1 -- #2 }

eventually becomes

\def\mymodule_foo:nn #1#2{#1--#2}

(genau wie \newcommand ). Es ist möglich, Funktionen ohne Signatur in ihrem Namen zu definieren, aber es wird im Allgemeinen nicht empfohlen: Dies wären Befehle auf Benutzerebene und es ist besser, \NewDocumentCommand für sie zu verwenden.

Andererseits,wenn Sie

\cs_new:Nn \mymodule_foo:N { --#1-- }

und rufen dann

\mymodule_foo:N {text}

TeX wird seinen eigenen Regeln folgen und den Code ohne Beanstandung akzeptieren, ungeachtet dessen, dass die Codierung aus expl3 -Sicht falsch ist.

Warum wird nicht erzwungen,dass die Argumente in der richtigen Weise angegeben werden,d.h.mit oder ohne Verstrebungen? Weil dies im Allgemeinen nicht möglich ist und in jedem Fall einen erheblichen Mehraufwand in Bezug auf Geschwindigkeit und Effizienz bedeuten würde.




In TeX - Ausnahme: LuaTeX-Engines - ist ein erweiterbares Betrachten des nächsten Tokens, um zu prüfen, ob es sich um ein explizites Kategorie-1-Zeichen-Token handelt, das ein Multi-Token-Argument bezeichnet, zB eine geschweifte öffnende Klammer der Kategorie 1, nicht möglich. Sie müssten etwas wie/basierend auf \futurelet verwenden , was eine Zuweisung ist, was impliziert, dass das betreffende Makro nicht in Erweiterungskontexten wie \write , \message , \csname..\endcsname , \edef , x / e / f / o -Erweiterung usw.

Besides this:

Wie "erzwingt" man zB x / e / f / o -Typ-Argumente?

Zitat aus Wikipedia : „In der Berechenbarkeitstheorie ist das Halteproblem das Problem, anhand einer Beschreibung eines beliebigen Computerprogramms und einer Eingabe zu bestimmen, ob das Programm zu Ende läuft oder für immer weiterläuft. Alan Turing bewies 1936, dass a Es kann keinen allgemeinen Algorithmus geben , um das Halteproblem für alle möglichen Programm-Eingabe-Paare zu lösen.

Einige Token eines e -Typ-Arguments könnten ein erweiterungsbasiertes Computerprogramm bilden; Einige andere Token des e -Typ-Arguments könnten aus Argumenten von Makros auf Benutzerebene stammen, die als Eingabe für das Computerprogramm betrachtet werden könnten. Das Überprüfen/"Erzwingen" eines e -Typ-Arguments könnte also beinhalten, eine ziemlich allgemeine Routine zu entwickeln, um zu prüfen, ob eine Erweiterung der Token, die das e -Typ-Argument bilden, wahrscheinlich eine Kombination aus einem erweiterungsbasierten Computerprogramm und einer Eingabe für diese Erweiterung ist -basiertes Computerprogramm – überhaupt beendet.

Vielleicht ist dies nicht genau ein Fall des Problems,einen allgemeinen Algorithmus für eine Turing-Maschine zu finden,der das Halteproblem für alle möglichen Programm-Eingabe-Paare löst,aber es erinnert mich daran.

Wie "erzwingt" man zB w -Typ-Argumente?

Wie "erzwingt" man zB T / F -Typ-Argumente?

Übrigens – unterschätzen Sie syntaktische Konventionen nicht – sie können beim Debuggen eine große Hilfe sein. ;-)

Sie können Makros/Steuersequenzen (auf Benutzerebene) definieren, bei denen die Angabe der Argumentsignatur nicht erforderlich ist – verwenden Sie einfach \cs_new:Npn oder Varianten davon. Das p -Type-Argument bezeichnet Parametertext wie bei \def .