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