User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Message-ID:  <55A8C0C2.3040908@morningstar2.co.uk>
Date:         Fri, 17 Jul 2015 09:45:54 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: expl3 boolean expressions: lazy evaluation
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Hello all,

expl3 current provides the idea of expandable boolean expressions in the
form

    \bool_if:nTF
      {
        ( <test-1> && <test-2> ) || <test-3> ...
      }

with lazy evaluation. However, as detailed in
https://github.com/latex3/svn-mirror/issues/217 there is an issue with
this: as parentheses are part of the syntax, any that are sent through
to the tests from 'above' can cause an issue. For example

    \cs_new:Npn \foo:N #1
      {
        \bool_if:nTF
          {
            \token_if_eq_charcode_p:NN + #1 ||
            \token_if_eq_charcode_p:NN - #1
          }

will fail if #1 is ")". This situation is clearly not ideal and we want
to find the best way to address it with minimal impact on real-world use
of \bool_if:n(TF).

It seems that any fix requires some change of documented behaviour. In
particular, we note that the problem can be dealt with if we drop lazy
evaluation. However, that might impact on current use cases. An obvious
issue is that something like the code currently in the expl3 driver
selection

    \bool_if:nTF
      {
           \cs_if_exist_p:N  \pdftex_pdfoutput:D
        && \int_compare_p:nNn \pdftex_pdfoutput:D > \c_zero
      }
      { pdfmode }
      { dvips }

will fail as the second test will not be skipped.  We note though that
this case is likely unusual: in general expl3 variables should be
declared before use so should. A quick sweep over TL2015 shows the
following packages would have to be updated following any change:

 - media9
  -ocgx2

(Other packages do use \cs_if_exist_p:(N|c) but not in a way which
relies on lazy evaluation.)

Are there other obvious issues if we switch from lazy evaluation? If the
change is to be made we intend to work with package authors in advance
to make sure that users are not impacted.
--
Joseph Wright