MIME-Version: 1.0
References: <4DA5C4E2.8090005@morningstar2.co.uk>
            <58AFBC3A-4209-4BC0-BB3A-5B14D6B5EFD8@gmail.com>
            <4DA727A9.2050903@morningstar2.co.uk>
            <BANLkTi=gG=oWHUaLyExNwQ6WzghSV6JXyQ@mail.gmail.com>
            <19880.45400.677093.956908@morse.mittelbach-online.de>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <BANLkTimfOA8TkQdB0uxtcFTbm3EqzHEAFw@mail.gmail.com>
Date:         Fri, 15 Apr 2011 18:19:35 -0400
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: The nature of popping from an empty sequence
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <19880.45400.677093.956908@morse.mittelbach-online.de>
Precedence: list
Status: R

> 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.