User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
References: <4A7921CF.5020803@morningstar2.co.uk>                              
            <4A7A1505.4040604@residenset.net>                                  
            <DB76B425-0A88-43B4-9CF0-B92FAF159E37@gmail.com>                   
            <4A7AD930.2090106@residenset.net>                                  
            <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com>                   
            <4A804317.6050909@morningstar2.co.uk> <4A80508F.3030904@elzevir.fr>
            <4A81C3D2.9040607@residenset.net>                      
            <4A826F15.8050606@morningstar2.co.uk>           
            <FEF49696-D7DB-4A35-9D3E-F19D97A19802@gmail.com>           
            <4A83A103.7020507@morningstar2.co.uk>
            <464C43D2-9841-45F6-9CEF-130C98A7CC86@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4A83B985.8030809@morningstar2.co.uk>
Date:         Thu, 13 Aug 2009 07:58:13 +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
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <464C43D2-9841-45F6-9CEF-130C98A7CC86@gmail.com>
Precedence: list
Status: R

Will Robertson wrote:
> Hi,
> 
> On 13/08/2009, at 2:43 PM, Joseph Wright wrote:
> 
>> Are we approaching a consensus on this (if not what everyone considers
>> ideal, at least on something most of us can live with)?
> 
> Seems great to me. I think it strikes a good balance.
> I'll be interested in hearing Morten's and Frank's views (although I
> understand they might not get the opportunity).

We haven't really deviated far from the xparse model as written by Frank
et al., so I'd hope he at least will be reasonably happy. It is more a
question of refinement and getting at least some parts finalised (to be
agreed once there is an implementation based on this discussion: perhaps
next week).

> As far as the definition of the processors is concerned, I think I
> prefer using a pre-determined toks variable rather than a more abstract
> "#1". That is, to write
> 
> { >{\my_sanitise:n} m }
> \cs_set:Nn \my_sanitise:n {
>   \toks_set:Nn \l_xparse_arg_toks { <something with #1> }
> }
> 
> rather than
> 
> { >{\my_sanitise:Nn} m }
> \cs_set:Nn \my_sanitise:Nn {
>   \toks_set:Nn #1 { <something with #2> }
> }
> 
> It looks better, to me, that processor functions have a single-letter
> signature in their simplest form. (It seems pretty clear that we should
> be using functions with expl3 names here?)

I'm fine with that.  On the naming of functions, xparse provides stuff
at design level, such as \IfNoValueTF. So we might consider a small set
of design-level functions, with the assumption that any extras would be
in internal namespace.  I'm thinking of a wrapper for \detokenize, and
perhaps a de-babel one (to remove active punctuation at the outer level).

> Also, I think this is about as simple as we can get. We could
> theoretically have a function like
>     \xparse_return_arg:n { <something with #1> }
> instead of the \toks_set:Nn, but this would still require scratch
> variables to manipulate #1 in the first place. So no gain.

Yes, we don't really gain much.
-- 
Joseph Wright