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
|