Will Robertson wrote:
> Hi Joseph,
> 
> Thanks for the great efforts here!
> I did a once-over on the documentation (and made a couple of minor
> adjustments) and everything seems logical to me.
> 
> To summarise the changes from the old xparse:
> 
> -  >{P} replaced by +
> -  >{W} dropped, since it is applied automatically when necessary (final
> optional argument(s))

Actually, for the moment I've simply not used any space skipping at all.
Of course, TeX skips spaces after the command name itself, but for
something like:

\foo{arg1}[arg2]{arg3}

it seemed easier to explain if there is no space skipping at a LaTeX
level. If other people disagree it is easy to change.

> -  c dropped, replaced by 'd()'

I'm imagining that LaTeX3 at the document level might well not need this
input type too much.

> -  g and G{} added: optional braced argument
> -  d** and D**{} added: pair-delimited argument
> -  u* and U*{} added: post-delimited argument

Just u{}: mandatory argument, no default but takes multiple tokens.

> -  >{\processor} added: "transforming" input before it's sent through to
> the main macro code
> -  Expandable document commands
> 
> I think that's it.
> 
> Nice to see the expandable document command definitions in there; I
> suppose time will tell whether they turn out to be useful or not...

I was quite happy that it turned out to be not too bad to code. I'd hope
people will take not of the warning that it is to be used in exceptional
circumstances.
>
> The only thing that sort of seems weird to me is that d** uses single
> tokens only as delimiters whereas u* allows multiple tokens. Is there a
> major technical reason that the d argument couldn't accept something
> like d{<<}{>>} for \foo<<1>> ? Actually, I don't care at all to support
> this sort of usage, but it just seems odd to have single tokens for one
> and multiple tokens for the other. Only a comment; I don't think
> anything needs to be done about it, at least at this stage.

The reason is the optional nature of D-family arguments (o, O, d, D).:
the same applies to t type arguments. For u (mandatory), all that is
ultimately needed is:

\cs_set:Npn \arg_grabber:w #1 <delimiter> { save #1 }

so <delimiter> can be whatever. On the other hand, for D family
arguments there is a test to see what the opening token is:

\cs_set:Npn \arg_grabber:w {
  \peek_charcode:NTF <opening-token> {
    \arg_grabber_aux:w
  }{
    \arg_grabber_aux:w <opening-token> <default> <closing-token>
  }
}
\cs_set:Npn \arg_grabber_aux:w <opening-token> #1 <closing-token> {
  save #1
}

To allow multiple opening tokens, there has to be one check (and
removal) for each token. That looks rather awkward to write, as you have
to be able to put back all of the removed opening tokens if not all are
actually present.

More generally, I'd hope that more complex options can be handled in
better ways than opaque argument syntax. Something like:

\foo[opt1][[opt2]]{arg} % Two opt args [...] and [[...]]

is probably better handled as:

\foo[opt1=text1,opt2=text2]{arg}

in any case.

> Lars, do you have any comments about whether the new xparse is something
> you'd like to use in your own work? Your code, of course, was the big
> motivation for the "argument processor" idea and I'd hope that while we
> didn't manage to fit everything from xdoc2l3 into xparse there's still
> enough that you'd like to use.

I'd hope we cover enough for almost all non-verbatim circumstances. For
example, taking Will's question of delimiters, you can make a mandatory
delimited argument with multiple tokens:

\DeclareDocumentCommand \foo { u{<open>} u{<close>} {
  \tl_if_empty:nTF {#1} {
    % Do stuff
  }{
    % Probably should not happen!
  }
}
-- 
Joseph Wright