User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
References: <4AE0BFB3.7080905@morningstar2.co.uk>           
            <8A015AE0-022B-4462-B8D5-CC1010E49205@gmail.com>
            <4AE18854.7080704@residenset.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <4AE1AE63.2000000@morningstar2.co.uk>
Date:         Fri, 23 Oct 2009 14:23:47 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: xparse processors
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4AE18854.7080704@residenset.net>
Precedence: list
Status: R

Lars Hellström wrote:
> From my point of view, there were two issues.
> 
> The first issue is that the given "return value register"
> \l_xparse_arg_toks is a toks when (in my experience) values (at least
> non-numeric values) are more commonly returned by defining a macro. This
> thus has to do with the ability to reuse existing code (in packages and
> such).

Yes, I can certainly see that point.

> The second issue is that the name \l_xparse_arg_toks would not fit in at
> all if using \DeclareDocumentCommand in e.g. the preamble of a document;
> one would have to fiddle around with the catcodes just to be able to
> type it, and the name is unintuitive.

I'd tend to regard processing an argument as something that is going to
show up mainly in blocks of code, not ad hoc definitions for functions
in a document. However, we loose nothing by allowing some flexibility.

> I suppose a compromise could be to use a fixed command name in the same
> class as \DeclareDocumentCommand -- e.g. \XparseResult or
> \XparseProcessorResult -- and do
> 
>   \let\XparseResult=\l_xparse_arg_toks
> 
> just before each processor; then the user can use this high-level name
> and not have to worry about the low-level LaTeX3 name. Furthermore this
> provides support for mixing macro- and toks-setting processors, as code
> that ends up doing \XparseResult={...} will access the toks register,
> whereas code that ends up doing \def\XparseResult{...} just breaks the
> association of \XparseResult to \l_xparse_arg_toks (as opposed to
> breaking xparse as a whole). Either way, V-expanding \XparseResult will
> recover what had been stored.

Taking this idea, I'd probably favour something that doesn't include
"xparse" as a document-level function: perhaps \ProcessedArgument or
\ProcessingResult? If I say that it will initially be a toks (for each
parsing run), then you can do

  \let\ProcessingResult\YourMacro
  \def\ProcessingResult{whtever}
  \toks_set:NV\ProcessingResult\Variable

etc. Would that work?
--
Joseph Wright