Print

Print


> I wonder if \prop_if_in:Nn(TF) isn't expandable (or rather could be made so,
> right now it is a protected conditional (for good)). If so then the fact
> that it is slower would be ok. I haven't tried, but one could probably build an
> expandable if_in as well - whether that's worth the effort is a differnt
> matter.

See below for an expandable if_in. However, it compares keys with
\str_if_eq:nn (to be expandable), so that imposes restrictions on
keys.

I feel like it is not a huge restriction for practical applications,
but I may be wrong. I would say that keys should be stored as is, but
compared as strings.


> Otherwise, if could be implemented by using internally get
> with some internal variable. In the latter cases it would be equally fast
> but fairly useless. The only difference being that you don#t have to
> unnecessarily specify a variable name you aren't using.

I prefer having an expandable test (with the string caveat explained above).

Right now, if_in is implemented with prop_split_aux, exactly like
prop_get, plus an extra \quark_...:nTF test. Probably slower than
using prop_get and \quark_...:NTF.

Regards,
Bruno

% I don't like much the fact that breaks are delimited by \q_stop.
% It should be a special \q_break, or not even a quark.
%
\cs_new_eq:NN \prop_map_break:n \use_i_delimit_by_q_stop:nw
\cs_new:Npn \use_ii_i:nn #1 #2 { #2 #1 }

\prg_set_conditional:Npnn \prop_if_in:Nn #1 #2 {p,T,F,TF} {
  \exp_after:wN \use_ii_i:nn
  \exp_after:wN {\toks_use:N #1} { \prop_if_in_aux:nNwn {#2} }
  { ? \prop_map_break:n { \prg_return_false: } }
  \q_prop { } % dummy arguments for the last \prop_if_in_aux:nNwn
  \q_stop
}
\cs_new:Npn \prop_if_in_aux:nNwn #1 #2 #3 \q_prop #4 {
  \use_none:n #2 % most often #2=\q_prop, except the last time
  \str_if_eq:nnT {#1} {#3} {
    \prop_map_break:n {\prg_return_true:}
  }
  \prop_if_in_aux:nNwn {#1}
}

% It is possible to use a similar approach (\use_none:n #2 with #2 being
% either one token or, at the end, more) to improve \prop_map_function:NN.