Hey Joseph,



Thanks for the comprehensive list!

Your suggestions are good in that they don't involve *too* much change  

from what we're used to. You got me thinking along the lines of some  

ideas Frank wrote down about a year ago. As you will see, this set of  

arg specs change things around quite a lot!



In the following table, "W" is a tentative suggestion following from  

some

comments by Frank last year; "J" is Joseph's suggestion, and "C" is what

we've got now.





W    J    C    Input            Output         Description



S    N    N    Single token     Unbraced       No expansion

      U    E    Single token     Unbraced       One expansion

T    O    O    Single token     Braced         One expansion

U    D         Single token     Braced         Double expansion

V              Single token     Braced         Triple expansion

W              Single token     Braced         "Special" expansion

Z    X    X    Single token     Braced         Full expansion



Which of these do we really need?

  - 'O' is needed for \glet:Oc -- or is it?

    Would writing \glet:oc be *that* bad?

  - 'N' is obviously needed

  - Can 'E' and 'X' be accommodated by 'e' and 'x' ?





n    n    n    Braced tokens    Braced         No expansion

a    o    o    Braced tokens    Braced         One expansion

b    d    d    Braced tokens    Braced         Double expansion

c         d    Braced tokens    Braced         Triple expansion

f    s    f    Braced tokens    Braced         "Special" expansion

x    x    x    Braced tokens    Braced         Full expansion





s              Braced tokens    Unbraced       No expansion

t    u    e    Braced tokens    Unbraced       One expansion

u              Braced tokens    Unbraced       Double expansion

v              Braced tokens    Unbraced       Triple expansion

w              Braced tokens    Unbraced       "Special" expansion

z              Braced tokens    Unbraced       Full expansion



These aren't that intuitive but on the other hand wouldn't be used too  

often.

Alternatively, they could be n!, a!, b!, ... with Morten's suggestion.





N    c    c    Braced tokens    (Un?)braced    Tokens to csname

A    e    C    Braced tokens    Braced         To csname, expand once

B              Braced tokens    Braced         To csname, expand twice

C              Braced tokens    Braced         To csname, expand thrice

F              Braced tokens    Braced         To csname, expand full

X              Braced tokens    Braced         To csname, expand all





K    R/K  D    Varies           Varies         Reserved/kernel only

W    W    w    Varies           Varies         "Weird" argument

p    P    p    Parameters       n/a            Primitive TeX parameters



      t    T    Braced tokens    Braced         True branch

      f    F    Braced tokens    Braced         False branch



What would happen if we dropped the true/false flags from the arg spec  

into

the function names? E.g.,

   \tlist_if_in_TF:nn { <tlist> }{ <str> } { <true> }{ <false> }



It's not perfect, but I think it's okay. It does remove the "funny  

case" that 'T' and 'F' branches represent in the argument  

specifications. And it would allow an arguably better syntax for  

bool_double:

   \bool_double_if_TT_TF_FT_FF:NN



(Although I suppose there's no reason we couldn't currently write

   \bool_double_if:NN_TT_TF_FT_FF )



***



Now, it would be a BIG JOB to actually make these changes. (Hmmm,  

maybe not. I guess regular expressions could do it without too much  

hassle.)



While we might be able to create a better system than we've got now,  

is it worth it?



W