User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
References: <4A720566.80504@morningstar2.co.uk>           
            <5BD2F1CD-3A4D-4204-889D-7E7CDA38F364@gmail.com>
            <4A740307.5000703@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4A77667A.5080400@residenset.net>
Date:         Tue, 4 Aug 2009 00:36:42 +0200
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: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= <Lars.Hellstrom@RESIDENSET.NET>
Subject: Re: \tl_add_braces:N ?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A740307.5000703@morningstar2.co.uk>
Precedence: list
Status: R

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. :-(