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