Joseph Wright skrev:
> Will Robertson wrote:
>> What sort of circumstances are you running into this? (Just out of
>> curiousity.)
> 
> This tends to be when constructing a list of tokens to possibly be added
> to something like \frac or sub/superscripted.  The token list is built
> up, then I need to wrap it up in braces so that whatever function I'm
> applying to it works correctly.  As far as possible, I'm keen to make
> the token lists I use end up the same as if they'd been done by hand: it
> makes debugging a lot easier.   For example:
> 
> \tl_set:Nn \l_tmpa_tl { abc }
> \tl_set:Nn \l_tmpb_tl { def }
> \tl_put_right:NV \l_tmpa_tl \l_tmpb_tl
> \tl_set:No \l_tmpa_tl {
>   \exp_after:wN { \l_tmpa_tl }
> }
> \tl_put_left:Nn \l_tmpa_tl { 10 ^ }
> 
> to end up with 10^{abcdef} in \l_tmpa_tl.

Hmm... IMHO, the awkwardness here is partly due to using a 
list-oriented API to construct what really is a tree (even though we 
must _store_ it in linearised form, as a list). In order to respect 
this tree structure, I'd probably rather do the last two steps as

   \def\l_tmpa#1{
      \def\l_tmpa_tl{10^{#1}}
   }
   \expandafter\l_tmpa \expandafter{ \l_tmpa_tl} % Or use \exp_args:No

if you pardon the primitives[*]. Of course, if the material isn't 
fragile -- the given example isn't -- then a single (protected) \edef 
is even simpler.

Lars Hellström


[*] I'm starting to doubt I'll ever manage a transition to l3names, 
myself... Sure, some parts are really nifty, but other parts seem bent 
on establishing a computational model for LaTeX that I'm not quite 
comfortable with.

Taking the above as example, I realise that one sometimes want 
operations that are precisely \tl_put_left:Nn or \tl_put_right:Nn, but 
those don't come naturally to TeX, solidly imperative that they are. 
When used for general programming, TeX tends to be better served by a 
functional/scripting/dynamic approach than an imperative one, but I 
suppose it is hard to show this off in the l3 documentation; since the 
scripting style doesn't suggest the creation of large libraries of 
"standard operations", someone who checks the list of available 
commands will mostly see the imperative stuff. :-(