Hi all,

I'll try to keep this brief; I've done my usual mistake of writing  
what's in my head and not impedance-matching it with what's in  
everyone else's. I'm skipping most of the discussion which I broadly  
agree with or don't think needs further discussion and jumping  
straight to the good bits.


Joseph Wright wrote:
> Lars Hellström wrote:
>> Nice to see more people joining the discussion.
>
> Of course, provided in the end we can all reach a decision we can at
> least live with. Different people have very different visions, it  
> seems.

I think we're all approximately on the same page :)




On 12/08/2009, at 10:26 PM, Lars Hellström wrote:
>
> The confusion saved is that one can make do with one scratch  
> variable that is private to xparse, instead of having several that  
> might have unclear sharing patterns.

I think I prefer this than to use an explicit argument. That is, write
     ... <do some stuff>\toks_set:Nn \l_xparse_result_toks  
{<results>} ...
rather than
     ... <do some stuff>\toks_set:Nn #1 {<results>} ...

> but that's untested (modification in e-mail of definition of x).  
> Also, I think "@" would be better than "?"; then @ would mean "drop  
> out to more general mechanism for this" at both the argument  
> specifier and processor level.

Yep, the '?' was partially to indicate I didn't care on the symbol :)


>> Secondly, for simplicity let's drop the idea of toks-grabbing as a  
>> proxy for argument grabbing.
>
> Not sure what you refer to here.

Sorry, I'm being unclear again. I just meant that I think we can drop  
the ={} type processing from xdoc2l3 that don't use #1, #2, ..., but  
rather named toks to refer to arguments.




On 13/08/2009, at 5:03 AM, Joseph Wright wrote:

> Lars Hellström wrote:
>
>> (The functionality of the above
>> \constrain_to_intrange:nnNn could be a candidate for inclusion into
>> xparse, but \MakeHarmless probably isn't.)
>
> I'm not sure \constrain_to_intrange:nnNn quite fits my idea of
> post-processing. I'm thinking of it mainly for standardising input
> rather than error-checking. However, that is a problem for rather  
> later,
> I think. If we can get the "basics" sorted, this type of thing can be
> finalised later.

The good thing about these argument post-processors is that we don't  
have to define *any* in xparse. I agree with Lars' sentiment that you  
don't need to give them single-letter names when you can describe what  
they do with functions. (While also providing single-letter names for  
the very most common ones.)





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.

Best regards,
Will