Hello Will,
> Thanks for the comprehensive list!
> Your suggestions are good in that they don't involve *too* much change
> from what we're used to.
That was largely because I'm broadly happy with the situation "as is".
I was thinking about the small-ish number of awkward cases, and trying
to make them clearer.
> In the following table, "W" is a tentative suggestion following from some
> comments by Frank last year; "J" is Joseph's suggestion, and "C" is what
> we've got now.
I did my best to stick with the current thinking (letters are based on
an explanation of what they do). You could perhaps include "z" in my
list as a complement to "W", with z representing other expansion
possibilities and W being more strictly for delimited arguments. In
that way, a z argument with always represent one thing, whereas W can
mean any arbitrary list of stuff.
> t T Braced tokens Braced True branch
> f F Braced tokens Braced False branch
>
> What would happen if we dropped the true/false flags from the arg spec into
> the function names? E.g.,
> \tlist_if_in_TF:nn { <tlist> }{ <str> } { <true> }{ <false> }
Speaking from my own experience, I quite like the :T, :F, :TF idea. The
problem with the above is that \tlist_if_in_TF:nn needs four arguments,
so it should really be \tlist_if_in_TF:nnnn. I think it is then much
harder to see what is going on. So if it were down to me I'd keep the
T/F idea, although I'd aim for lower case as these can take braced
arguments. (Speaking of which, I might revise my suggestion again, to
stick with :w in lower case for the same reason: braces are possible for
:w arguments.)
> (Although I suppose there's no reason we couldn't currently write
> \bool_double_if:NN_TT_TF_FT_FF )
Why not just \bool_if:NN_TT_TF_FT_FF? A slight abuse of the system, but
this is one of those edge cases where flexibility is needed.
> While we might be able to create a better system than we've got now, is
> it worth it?
Once again, if it were down to me I'd not make more changes than are
really needed. In that sense, this entire discussion could be somewhat
redundant: things already work reasonably well. I'd still argue that
\exp_after:NN is not representative of what it does, so using the
current specifiers would prefer \exp_args:NE. That change at least
should be relatively easy.
If other changes are made, I'd suggest that there will be something of a
"knock on" effect, and so it is only worth doing if the entire result is
more logical (e.g. just changing f => s is not worth it). Of course, I
think my suggestion is not bad :-)
--
Joseph Wright
|