Will Robertson wrote:
> 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.

When Lars first mentioned his stuff, I wasn't really up to speed on the
idea.  I did take a good look, and reached much the same conclusion as
Will. Particularly if \DeclareDocumentCommand is to replace \newcommand
for users, as well as programmers, things need to be reasonably clear.

>> 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.

Will is on the nail here. The advantage of two different letters for
optional argument and optional argument + default is that it avoids this
question. Perhaps that scheme is better over all, even though we then
need an extra letter.  How about:

- n = optional argument with no default
- o = optional argument with default (which must therefore be specified)
- b = optional braced argument (as Will wanted "n" for this)

That leaves what I've done with the delimited "d" specifier. That is
less commonly used, so perhaps Lars suggestion is best here: you always
give a default, even if it is \NoValue.

>>> 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.

Okay, this seems to be a consensus: we'll say that this is a must.
>> 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.

I'm with Will: I'm not sure I follow :-(

> 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.

That is what I've tried to stay focussed on.  It does mean some stuff is
dropped, but overall I'd hope we need "enough power for 90% of tasks".
-- 
Joseph Wright