Generalising \cs_generate_variant

[aparsloe]

I have found a number of instances where I have wanted to generate a
variant with varying degrees of branching, e.g.

\cs_generate_variant:Nn \tl_case:Nn { No }
\cs_generate_variant:Nn \tl_case:NnT { No }
\cs_generate_variant:Nn \tl_case:NnF { No }

I find myself envious of the functionality available with
\prg_new_conditional:Npnn and its ilk where multiple degrees of
branching can be coded in a single statement using a subset of { p, F,
T, TF }. It would be nice to be able to write something similar, e.g.

\cs_generate_variant:Nnn \tl_case:Nn { No } { , F, T }

where the empty slot before the first comma denotes the nonbranching
variant.

I don't imagine I'm the first to have thought this, so presumably there
is good (or at least some) reason for not providing the functionality.
It would be good to know.

Andrew

[Joseph Wright]

Post by aparsloe
I have found a number of instances where I have wanted to generate a
variant with varying degrees of branching, e.g.
\cs_generate_variant:Nn \tl_case:Nn { No }
\cs_generate_variant:Nn \tl_case:NnT { No }
\cs_generate_variant:Nn \tl_case:NnF { No }
I find myself envious of the functionality available with
\prg_new_conditional:Npnn and its ilk where multiple degrees of
branching can be coded in a single statement using a subset of { p, F,
T, TF }. It would be nice to be able to write something similar, e.g.
\cs_generate_variant:Nnn \tl_case:Nn { No } { , F, T }
where the empty slot before the first comma denotes the nonbranching
variant.
I don't imagine I'm the first to have thought this, so presumably there
is good (or at least some) reason for not providing the functionality.
It would be good to know.
Andrew

I don't remember any technical reasons for not doing this: I guess
primarily we've not needed it often enough.

Probably this would go into \prg_... as it's only applicable to
conditionals (we have \prg_new_eq_conditional:NNn and
\prg_set_eq_conditional:NNn). I guess something like
\prg_generate_conditional_variant:Nnn would be an appropriate name.

Thoughts?
--
Joseph Wright

[aparsloe]

Post by Joseph Wright

Post by aparsloe
I have found a number of instances where I have wanted to generate a
variant with varying degrees of branching, e.g.
\cs_generate_variant:Nn \tl_case:Nn { No }
\cs_generate_variant:Nn \tl_case:NnT { No }
\cs_generate_variant:Nn \tl_case:NnF { No }
I find myself envious of the functionality available with
\prg_new_conditional:Npnn and its ilk where multiple degrees of
branching can be coded in a single statement using a subset of { p, F,
T, TF }. It would be nice to be able to write something similar, e.g.
\cs_generate_variant:Nnn \tl_case:Nn { No } { , F, T }
where the empty slot before the first comma denotes the nonbranching
variant.
I don't imagine I'm the first to have thought this, so presumably there
is good (or at least some) reason for not providing the functionality.
It would be good to know.
Andrew

I don't remember any technical reasons for not doing this: I guess
primarily we've not needed it often enough.
Probably this would go into \prg_... as it's only applicable to
conditionals (we have \prg_new_eq_conditional:NNn and
\prg_set_eq_conditional:NNn). I guess something like
\prg_generate_conditional_variant:Nnn would be an appropriate name.
Thoughts?
--
Joseph Wright

Correction: I meant to write

\cs_generate_variant:Nn \tl_case:Nn { o }

etc., expanding the token list variable.

Andrew

[Will Robertson]

Post by Joseph Wright
I don't remember any technical reasons for not doing this: I guess
primarily we've not needed it often enough.

I think this was discussed back when I first came on board years ago, and naming complexity / interface simplicity relegated it to the chopping room floor. This was probably before we even had selection of conditions in the {p,TF,T,F} style argument.

Post by Joseph Wright
Probably this would go into \prg_... as it's only applicable to
conditionals (we have \prg_new_eq_conditional:NNn and
\prg_set_eq_conditional:NNn). I guess something like
\prg_generate_conditional_variant:Nnn would be an appropriate name.

I think another complaint I had at the time was that “\prg_generate_conditional_variant:Nnn” is a pretty big mouthful of a command, but that’s minor :) I don’t think we could come up with a shorter and better name but any ideas?

Cheers,
Will

[aparsloe]

Post by Will Robertson

Post by Joseph Wright
I don't remember any technical reasons for not doing this: I guess
primarily we've not needed it often enough.

I think this was discussed back when I first came on board years ago, and naming complexity / interface simplicity relegated it to the chopping room floor. This was probably before we even had selection of conditions in the {p,TF,T,F} style argument.

Post by Joseph Wright
Probably this would go into \prg_... as it's only applicable to
conditionals (we have \prg_new_eq_conditional:NNn and
\prg_set_eq_conditional:NNn). I guess something like
\prg_generate_conditional_variant:Nnn would be an appropriate name.

I think another complaint I had at the time was that “\prg_generate_conditional_variant:Nnn” is a pretty big mouthful of a command, but that’s minor :) I don’t think we could come up with a shorter and better name but any ideas?
Cheers,
Will

A not-too-zealous look through the index to Interface3.pdf gives, in
descending order, of length

39 characters
\peek_charcode_remove_ignore_spaces:NTF

38 characters
\peek_catcode_remove_ignore_spaces:NTF
\__fp_basics_pack_weird_high:NNNNNNNNw

37 characters
\prg_generate_conditional_variant:Nnn
\__msg_kernel_expandable_error:nnnnnn
\use_i_delimit_by_q_recursion_stop:nw

so \prg_generate_conditional_variant:Nnn, although uncomfortably long,
would not be a record holder.

Andrew