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>
Message-ID:  <FFBA056D-6B16-4FB2-AD0F-CD95B6719230@gmail.com>
Date:         Thu, 27 Nov 2008 17:40:59 +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:  <859ec5630811200508x17ef357dvc7cf352f5bc1031f@mail.gmail.com>
Precedence: list
Status: R

Hi,

Sorry for my delay in replying to this. Some context before my  
comments. I'm afraid I've only been able to thinking a little about  
the whole problem, but I wanted to jot down my thinking before it  
evaporated.

IDEA 1:

> I tried to address the situation with the E specifier, which is the
> same as O except the braces are removed.

[snip]

IDEA 2:

> Here's a crazy idea. What if in the argument specifiers, we use a
> special symbol for denoting that the next argument is to be returned
> without braces? Such as for example \exp_args:N!o or so which would
> pass N unchanged and then ``unbrace'' the result of the o expansion.

[snip]

IDEA 3:

> However, it is my feeling that for most practical purposes you only
> wish to remove braces from the very last item in the expansion chain.
> Therefore, a simpler naming scheme such as
>  \exp_args_u:NO
>  \exp_args_u:NNo
>  etc.
> could be employed.

***

In order of preference, I think I like idea 1, then 2, then 3. It  
seems like with the current system, we can't really anticipate every  
possibility of weird expansion that comes along.

Arg specs n, N, w, D, e, E can be ignored for this discussion, so  
here's what's left: (since an 'n' argument has no added braces)
o O
x X
   C
f
d

(While I notice this, I think we should change 'd' to 'u' -- say -- to  
avoid the similarity with 'D'.)

(Another thing: I search for \\[a-zA-Z_]*:[a-zA-Z]*X and I don't think  
there are any 'X' variants defined anywhere, even in l3expan. I'll  
probably remove it from the expl3 documentation soon-ish.)

'e' and 'E' take the place of unbraced 'o' and 'O'.
But that still leaves

'x' -- 'X' could now have a changed meaning to mean "unbraced"
'f' -- 'F' to follow the same logic
'd' -- Hmmm ('u' and 'U' might work)
'C' -- Hmmm
(And what about the hypothetical "make csname and expand twice"  
scenario, etc.?)

So it looks like it gets pretty messy dealing with all these extra  
letters.

In which case Morten's '!' idea sounds pretty good.

Generally I'm somewhat opposed to referring to the handling of the  
arguments in the main name of the function.

But my thoughts are all fairly uninformed, without much experience of  
actually writing any expansion code.

Must run with this email slightly unfinished,
Will