xparse/expl3 中是否已经有一个（可扩展和延伸的）接口，用于测试一组标记（可能来自 expl3-n-type 参数或 xparse-m-type 参数）是否与可指定的模式匹配，从而反过来可以通过提供参数说明符列表来指定该模式？
或者你必须自己修改一些东西，例如使用 l3regex 而不是仅仅提供参数说明符列表？
（我之所以问这个问题是因为我不想重新发明轮子以防它已经存在。）
如果没有这样的界面我就不会要求别人为我写这样的东西。
如果没有这样的接口，我问是否创建这样的接口
- 有道理吗？（我知道，这在一定程度上可能是基于观点的，但也可能有我不知道的忽略这种界面的技术/事实原因。）
- 已经讨论过了，如果是的话，我可以在哪里了解更多其他人对此的看法？
就像是
\AtIfTokensFitPattern{⟨tokens to test⟩}%
{⟨list of argument-specifiers⟩}
{⟨tokens in case ⟨tokens to test⟩ fit the pattern denoted by the ⟨list of argument-specifiers⟩⟩}%
{⟨tokens in case ⟨tokens to test⟩ don't fit the pattern denoted by the ⟨list of argument-specifiers⟩⟩}在
\NewDocumentCommand\macro{ommm}{%
Some replacement text where arguments
\IfNoValueTF{#1}{}{\string##1=#1 and }
\string##2=#2 and
\string##3=#3 and
\string##4=#4 are used.%
}
...
\NewDocumentCommand\CallMacroWithArgumentOnlyIfPossible{m}{%
\AtIfTokensFitPattern{#1}{ommm}{\macro#1}{%
\PackageError{MyPackage}%
{Cannot call \string\macro}%
{The argument must match the argument-pattern of \string\macro!\MessageBreak
Otherwise it cannot be passed to \string\macro\space without errors!}%
}%
}%
...
\CallMacroWithArgumentOnlyIfPossible{[A]{B}{C}{D}} → \macro[A]{B}{C}{D}
\CallMacroWithArgumentOnlyIfPossible{{1}{2}{3}} → \macro{1}{2}{3}
\CallMacroWithArgumentOnlyIfPossible{{a}{b}} → \PackageError{MyPackage}%
{Cannot call \string\macro}%
{The argument must match the argument-pattern of \string\macro!\MessageBreak
Otherwise it cannot be passed to \string\macro\space without errors!}%
当将宏参数传递给其他宏时，这样的接口可能会很有用。
例如，与 pgfkeys 或 l3keys 包等 key=value 处理器结合使用：
假设您有一个键，其中需要一个值，并且可能出现两种情况：
如果形成值的标记符合参数模式
⟨方括号中的可选参数⟩⟨强制参数⟩⟨强制参数⟩⟨强制参数⟩
前面加上标记
\macro；\macro表示根据指定的参数模式处理标记的宏。即，在值中可选参数可能存在也可能不存在。如果值不符合指定的参数模式，则会引发可理解的错误消息。 （如果（某些）强制参数未嵌套在括号中，也可能引发错误消息。）
这个问题更像是一个学术问题，源于通过基于 l3keys 的 key=value 接口将参数传递给其他宏的场景。
例如，
crefname={singular}{plural}
应导致
\crefname{some counter}{singular}{plural}
被执行。
更普遍的 应该导致 被执行。
crefname=⟨value⟩
\crefname{some counter}⟨value⟩
（\crefname在 cleveref 包中定义。）
⟨value⟩然而，只有当形式上对应于两个未限定的宏参数时，这种方法才有效。
我可以针对这个特定场景编写测试程序。
我感兴趣的是，是否已经有一个通用接口，用于测试一组标记的元素是否可以根据某些参数文本/根据某些 expl3/xparse-argument-specifiers 列表分配给一系列参数。
一般的测试是这样的：
方法 1：
如果存在，则根据参数说明符列表逐一吞噬参数。如果不存在非可选参数，则标记集与指定的参数模式不匹配。如果吞噬所有参数说明符下的参数后仍有剩余，则标记集与指定的参数模式不匹配。
因此，对于每种参数类型，您需要测试标记序列的前导标记是否构成这样的参数。对于可选参数，这些测试已经实现。然后，您可以实现测试和吞噬的循环。
对于分隔参数，可能需要动态定义测试和吞噬宏。
方法 2：
附加到标记集以测试另一组标记，该标记形成与参数说明符列表匹配的参数序列。将宏应用于结果，该宏一次性根据参数说明符删除参数。如果其余部分恰好由附加的标记组成，则所讨论的标记集与参数模式匹配。
无论如何，对于扩展发挥作用的论点，事情可能会变得棘手，因为您需要处理这样一个事实：测试扩展是否既不产生错误也不产生无限循环，这似乎是百分百可靠的，这似乎是不可行的。（这个问题让我想起了艾伦图灵和停机问题。）