## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Classic View Use Proportional Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Thu, 3 Sep 2009 14:43:19 +0200 Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]> Subject: Re: xparse MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <[log in to unmask]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed From: Lars Hellström <[log in to unmask]> Parts/Attachments: 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{} (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 > > which is the same action if 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    >{}{} with the semantics that xparse will execute    {} and expects to afterwards find the result in the ,[*] 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