Hi Lars,

On 06/08/2009, at 8:55 AM, Lars Hellström wrote:

> I should perhaps point out that I've also explored some variations  
> on the xparse theme (Jan 2008, in a package I called xdoc2l3 -- see http://abel.math.umu.se/~lars/xdoc/) 
> , but back then I didn't get much response to the questions that  
> required *decisions* (and then I got distracted by other projects).  
> I will mention the issues I recall at suitable locations below.

I'm afraid that I agree with Joseph that regardless of the technical  
merits of xdoc2l3, the approach it takes sacrifices some measure of  
simplicity for flexibility. And even with the flexibility we run into  
the problems of TeX itself -- sure, we can change catcodes, but only  
if it's not nested within an argument. And even if we use \scantokens,  
% still kills things.

> Optional arguments of argument specifiers?!? My feeling is that  
> optional, star-type, etc. arguments should be considered user-level  
> syntactic sugar, and that the programming APIs should rather stick  
> with mandatory arguments and signals like \NoValue.  
> \DeclareDocumentCommand could be user-level enough that optional  
> arguments make sense, but there is the alternative of having it be
>
> \DeclareDocumentCommand \foo { o{\NoValue} m }
>    % Optional argument with no default (returns \NoValue)
> \DeclareDocumentCommand \foo { o{default} m }
>    % now has a default!
>
> Recall that \newcommand and friends require you to specify a default  
> value for the optional argument whenever there is one.

The one advantage I can see to allowing { o m } is that there is then  
a standard technique for testing with \IfNoValueTF, rather than having  
package authors write things like
    ... { o{\q_nil} m }
        { ... \quark_if_nil:NTF #1 {}{} ... }
which mean the same thing but look different.

>> The current xparse implementation lets you create your own specifier
>> letters. This is probably very risky:  what if two packages use the  
>> same
>> letter?  I'd drop this idea.
>
> Agreed. An analogy with array package definitions of new column  
> specifiers fails because there it is usually the document author who  
> would make the definition, thus confining the definition to code  
> under the control of that author, whereas with xparse it would be  
> arbitrary package authors that don't have such confinement.

Double agree. Good argument.

>> Thinking about catcode-sensitive input, most cases can be handled  
>> by the
>> e-TeX tools we have available. For true verbatim input, that  
>> obviously
>> does not work, but I feel that truing to "crowbar" verbatim input  
>> xparse
>> is a mistake.  Almost all user functions are not verbatim, and the
>> particular issues for those that are, I think, better handled by  
>> hand.
>> (The way that xparse works means that it absorbs arguments before
>> passing them to the code you program.)  I also suspect that xparse
>> handling of verbatim will never be reliable enough for general use.
>
> Is that a yes or no to my "harmless character sequences"? These can  
> handle data like URLs which might prompt people to go verbatim, but  
> they aren't implemented using \catcode changes.

Not sure I understand -- even URLs need to sanitise % if they're used  
within an argument.


>> Finally, the question about expandability of \IfNoValue has been  
>> asked
>> before.  As \DeclareDocumentCommand only ever makes \protected
>> functions, I don't think we need to worry.
[snip]
> a great advantage of \NoValue is that it can be passed around  
> without syntactic difficulties, so the actual test might happen in a  
> distant helper macro or even completely separate from the \foo  
> command (if the argument is stored away in a token list). Finally,  
> you're thinking too imperatively about the whole thing, thus  
> discarding the possibility of performing such tests at expand-only  
> time.

No real comment about this. I agree with Joseph that if everything is  
protected then the expandability of \IfNoValue becomes less important.

> Other possible xparse features I'd like to see discussed (and recall  
> right now) are:
>
> * The ability to preprocess (e.g. evaluate as a calc expression)
>   an argument before handing it to the command body.

Since expl3 functions allow you to evaluate calc expressions anyway,  
what advantage would there be to this?

> * The ability to have arguments assigned to token lists rather
>   than handed as macro parameters (lets one get around the 9
>   parameter limit).


If we attempt to keep things simple, then I think this is stretching  
the limits of what we'd like \DeclareDocumentCommand to achieve.  
Besides, I've never seen an argument for when >9 arguments are  
actually necessary that couldn't be implemented in some other way  
(e.g., keyval or csv list).

I think a goal for xparse should be simplifying the majority of  
approaches taken by package writers, and leave the esoteric stuff to  
continue to be implemented by hand.

Will