Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
References: <LISTSERV%200811192230181624.04A3@LISTSERV.UNI-HEIDELBERG.DE>      
            <27990a880811191758x2a29ecb4m33d2dcead1f32093@mail.gmail.com>      
            <859ec5630811200508x17ef357dvc7cf352f5bc1031f@mail.gmail.com>
            <FFBA056D-6B16-4FB2-AD0F-CD95B6719230@gmail.com>
            <492E623B.1090300@morningstar2.co.uk>
            <492F05D6.3060103@morningstar2.co.uk>
Message-ID:  <1F3BAD8F-E4CF-4110-8D8E-50B31B47FB22@gmail.com>
Date:         Fri, 28 Nov 2008 13:21:15 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: \exp_after:NN
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <492F05D6.3060103@morningstar2.co.uk>
Precedence: list
Status: R

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