Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v935.3)
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>
Content-Transfer-Encoding: 8bit
Message-ID:  <284EF6D6-0607-42A7-A014-6DB8002562C5@gmail.com>
Date:         Wed, 26 Aug 2009 10:35:17 +0930
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A946AD7.4020506@residenset.net>
Precedence: list
Status: R

Hi Lars,

Just a minor point or two.

On 26/08/2009, at 8:21 AM, Lars Hellström wrote:
>
> One noticable difference to what I believe was discussed is in the  
> order of processors. If ">{A} o" means "grab optional argument, then  
> apply A", then I think it stands to reason that ">{B} >{A} o" should  
> mean "grab optional argument, then apply A, finally apply B", but as  
> implemented in revision 1494 it's B before A. (Reversing the  
> processing order would allow one to do without  
> \l_xparse_processor_use_int.)
>
> If you find it important that processors should be applied in left- 
> to-right order, then I believe they should appear after the argspec  
> base, perhaps as "o <{A} <{B}", to keep as invariant that the thing  
> being done first is closest to the argspec base. (SYNTAX CHANGE)  
> This may also have the added value of being more intuitive for users.


I don't have strong opinions on the matter, but:
(a) I prefer '>{A} m' over 'm <{A}'
(b) I agree right-to-left makes some sense

>    \exp_args:NnV \@firstofone {#2} \l_xparse_arg_toks
>       % How do without \@firstofone here?

The problem is that \exp_args are designed for expanding arguments  
being passed to a function, not for general expansion control; as  
you've noticed this means they have a tendency to surround everything  
with braces.

I've proposed some extensions to \exp_after to allow this sort of  
thing (e.g., \exp_after:nV which would not brace-surround the first  
argument) but it hasn't been clear if it's useful enough, yet.

(Also, instead of \@firstofone you can use \use:n if you wish)

> In the typeset form, there is an index which should provide the same  
> functionality via hyperlinks (although for some reason all the links  
> seem to go to page 1; is that just for me or is it broken in l3doc  
> in general?)

I've had similar problems in the past but they generally clear up with  
some magic number of LaTeX runs after the index generation. Or l3doc  
could be broken; it's not particularly nice code at the moment (my  
fault).

> Some further introspection reveals that this happens inside an  
> expansion of \g_doc_functions_seq, which is very, VERY long. Hence I  
> suppose this "infinite loop" may in fact be an O(n^2) operation for  
> a very large n. Perhaps you should examine switching to a faster  
> algorithm, or provide some indication of progress?

Indeed, what \g_doc_functions_seq is being used for is quite  
unnecessary for source3. This is disabled in the Makefile; I should  
probably turn it off by default in l3doc and only enable it when  
necessary.

(It's checking that the functions documented with \begin{function} are  
also implemented with \begin{macro}, and warning of cases where  
functions have been implemented without documentation or vice versa.)

In the meantime you should have more luck with `make sourcedoc`.

Hope this helps,
Will