On 13/08/2014 10:42, aparsloe wrote: > I have been using l3regex and tripped on the following circumstance. > Suppose > > \tl_set:Nn \l_tmpa_tl { abcdef } > > Then > > \regex_replace_all:nnN { cd } { 12 } \l_tmpa_tl > > results in \l_tmpa_tl containing ab12ef, but there is no built-in > function for the analogous match or extract function. This was > disconcerting for a moment, to discover that I could replace text but > couldn't match it. Of course I can, but it means resorting to > \exp_args:Nno as in > > \exp_args:Nno \regex_match:nnTF { cd } \l_tmpa_tl { true } { false } > > It would be consistent with the presence of \regex_replace_all:nnN and > \regex_replace_all:NnN if there were corresponding functions, > \regex_match:nN and \regex_match:NN, and similarly for extract. > > In the context in which I was working, the token list variable > (analogous to \l_tmpa_tl above) is set to a mathematical formula > elsewhere in the code. The formula is most naturally handled in this way > as a token list variable rather than as a token list. > > Andrew There's a difference here between the two situations: in the replace case, you need to have an N-type argument as you've got to have a tl to set at the end of the process. On the other hand, in the case of matching it's unimportant if the tokens are given in a tl or are given explicitly. So \cs_generate_variant:Nn \regex_match:nnTF { nV } \regex_match:nVTF { cd } \l_tmpa_tl { true } { false } would be my preference here. (We don't claim to define all possible variants up-front, but there is nothing stopping you adding ones which are useful.) -- Joseph Wright