Will Robertson wrote:
> Lars Hellström wrote:
>>
>> For the record, the syntax I'd currently prefer for that is
>>
>>  {
>>    @{ @{\preprocessorb} @{\preprocessora} O{default} }
>>    m o m
>>  }
> 
> For the sake of argument, assume that we're paring down the
> functionality of xdoc2l3 to only this and nothing more. (Is that a
> reasonable assumption?) While I understand where this one comes from, do
> you think at this level that it makes sense to use @ for both for
> "bracing" and for "preprocessor defining"? I think I'd be more
> comfortable with something like any of the following:
> 
> 1.    { m @{ >{\preprocessorb} >{\preprocessora} m } o m }
> 2.    { m  { >{\preprocessorb} >{\preprocessora} m } o m }
> 3.    { m  [ >{\preprocessorb} >{\preprocessora} m ] o m }
> 4.    { m    >{\preprocessorb} >{\preprocessora} m   o m }
> 
> If technically possible, I #4 is actually the clearest by virtue of
> being the simplest. If the latter syntax is not technically possible,
> I'd prefer to optimise the syntax for the case of a single preprocessor,
> I think. Writing
>     { @{ @{\preproc} m } }
> is somewhat cumbersome. A simplification to
>     { >{\preproc} m }
> would work well even if example #4 above can't work.

I'd also been thinking in similar terms. I'm not very keen on "mix and
match" with "m = @ { }" type short-cuts (I like the fact that you can
currently count the letters and it is equal to the number of arguments).
I'd think Will's #4 is perfectly feasible at an implementation level.
The logic is simply:

  - If token is +, set \long flag
  - If token is >, collect argument into (say) \l_xparse_processors_seq
  - Otherwise, fire argument-builder

Each argument-builder can then unwind \l_xparse_processors_seq, leaving
it empty for the next gathering run. (I'd imagine that s/t would simply
ignore any > arguments, and also +, as it is not really applicable.) The
"all" the code has to do is recover the processor and get to to act on
the value to be processed (either user input or output from previous
processor).

I don't feel that this plan is too complicated, as most of the time
there will either be no post-processing at all, and even if there is
post-processing one function is most likely.

Are we approaching a consensus on this (if not what everyone considers
ideal, at least on something most of us can live with)?
-- 
Joseph Wright