Hi Joseph, You got two things backwards: the order of the arguments (maybe that means it should be revised), and the order of the parameters of \c. > : Although it is not yet in l3kernel, I wonder if this is a job for the > : l3regex module that Bruno has written. Using a regex, it is possible to > : specify complex token list requirements without needing lots of > : dedicated functions (at the cost of performance). (The regex code is in > : l3experimental.) For example, The following shoul (I hope) match a token > : list made up entirely of letters with category code 'letter' > : > : \regex_match:nnTF { <tokens> } { ^\c[a-zA-Z]L+$ } ... Should be \regex_match:nnTF { ^ \cL[a-zA-z]+ $ } { <tokens> } ... instead (if that doesn't work, it's a bug and I'll investigate). > Thanks. For token lists, the regex module seems more appropriate than > my proposal. Also I have to admit that I hadn't looked at the regexp > module yet. It certainly lets me do what I need. However, I think the > functions I proposed are useful on their own. I've been wondering: should it be called "regex" or "regexp"? Like Joseph, I don't see how useful the functions you propose are. Do you have a precise use case? I think that what you propose can be done (in the non-expandable case) as (say for the "some" version): \bool_set_false:N \l_my_bool \tl_map_inline:Nn \l_my_tl { \my_conditional:nT {#1} { \bool_set_true:N \l_my_bool \prg_map_break: } } \bool_if:NTF \l_my_bool { <my conditional was true at least once> } { <my conditional was never true> } I hope this helps. Regards, Bruno