LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Fri, 28 Nov 2008 13:21:15 +1030
text/plain (91 lines)
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  
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  
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  
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  

(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  

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