LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Lars Hellström <[log in to unmask]>
Thu, 3 Sep 2009 14:43:19 +0200
text/plain (63 lines)
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

ATOM RSS1 RSS2