User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
References: <4A7921CF.5020803@morningstar2.co.uk>                              
            <4A86949D.3090500@morningstar2.co.uk>                              
            <4A886BA8.2000209@morningstar2.co.uk>                              
            <0417DF73-EC19-4262-B9DF-5C870D47BFCE@gmail.com>                   
            <4A893816.2090807@residenset.net>                                  
            <4A89610D.8060108@morningstar2.co.uk>                              
            <4A8C71CC.7000006@residenset.net>                      
            <4A8D0048.4070101@morningstar2.co.uk>           
            <4A946AD7.4020506@residenset.net>
            <4A9EC61D.5000502@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4A9FB9E7.40902@residenset.net>
Date:         Thu, 3 Sep 2009 14:43:19 +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: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A9EC61D.5000502@morningstar2.co.uk>
Precedence: list
Status: R

Joseph Wright skrev:
> Lars Hellström wrote:
>> Finally, there is the issue that a processor has to put the argument in
>> a toks register. I understand this is for generality (only sane way to
>> pass along # tokens), but my experience with this type of API is that
>> one should make it easy to use commands that happen to already exist. In
>> this case, it would mean to also support a processor that would store
>> its result in a macro rather than a toks register, since I'm quite sure
>> this is what people tend to do unless they definitely need a toks register.
> 
> Maybe I'm missing something here, but if we need the processed value
> returned in a named variable it should not matter whether it is a toks
> or a tl (or indeed anything else).

The point is that when specifying a processor, it's kind of a drag 
having to introduce a helper function just for the purpose of glueing 
xparse's syntax to that of an existing command really implementing the 
operation; it would be much better if the syntaxes fitted from the 
start. For operations that produce a sequence of tokens as result, I 
believe the most common syntax would be the same as for \MakeHarmless, 
i.e.,

   \MakeHarmless<tl-to-set-to-result>{<input>}

(other examples more or less matching that syntax are \def and \edef). 
Token registers, in my experience, is something you avoid using as 
variables unless you have a specific need for them.

> All that needs to happen is
> 
> \toks_set:NV \l_xparse_arg_toks <variable-used-in-processor>
> 
> which is the same action if <variable-used-in-processor> is a tl or a
> toks.

Yes, but it is awkward to put that piece of code in the >{...} 
modifier, since it must be executed *after* the actual processing step 
has been carried out -- it pretty much requires a helper function to 
rearrange things. Hence my suggestion that /xparse/ should supply that 
piece of code, rather than rely on the user to do it.

Actually, a thing that worries me about the >{} syntax discussed so far 
is that it presumes the programmer doing \DeclareDocumentCommand has 
\ExplSyntaxOn, which I don't think is a safe bet; we're talking about 
something which is somewhat like \newcommand. A better syntax might be

   >{<variable>}{<processor>}

with the semantics that xparse will execute

   <processor>{<argument>}

and expects to afterwards find the result in the <variable>,[*] which 
it can then transfer to \l_xparse_arg_toks or perhaps pass directly to 
the next processor. This adds the ability to use processors that leave 
their result in a fixed place, but more importantly it avoid tying the 
argspec syntax to implementation details of xparse.

[*] Okay, here that automagic "V" expansion type actually turns out to 
be useful. :-o

Lars Hellström