MIME-Version: 1.0
References: <55A8C0C2.3040908@morningstar2.co.uk>
            <20150717095912.GA6487@hzdr.de>
            <55A8E267.1030901@morningstar2.co.uk>
            <20150717140025.GA10619@hzdr.de>
            <55A90BC0.6020102@morningstar2.co.uk>
            <CABceR4bRTfa_L9Kx-Wx2k2bWkWtOng+OyZjr231F6UDXoMkPLw@mail.gmail.com>
            <CABceR4ZK4k1Xziw4J5yTQ8kx5jt05FpRpBH1ifwU_t96K3Ot-w@mail.gmail.com>
            <CANQYN6yPQVuFezJhANo96dzy9Ha44Y7MS5rzcbALN5j6vuvg7w@mail.gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c07a850998443051caf91d1
Message-ID:  <CABceR4acTaPCcLAKZ+5-2aAewP5cEYKmWuekbCOd8V8ib2gN0w@mail.gmail.com>
Date:         Fri, 7 Aug 2015 02:41:01 +0000
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: Sean Allred <allred.sean@GMAIL.COM>
Subject: Re: expl3 boolean expressions: lazy evaluation
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CANQYN6yPQVuFezJhANo96dzy9Ha44Y7MS5rzcbALN5j6vuvg7w@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

--94eb2c07a850998443051caf91d1
Content-Type: text/plain; charset=UTF-8

Hi Bruno :)

Disclaimer: I've completely reversed my stance on this. See below.

> Can you clarify what your suggested \bool_validate:n is meant to do?
> Your description is too short for me to have any idea what it is.

\bool_validate:n is just a thought to allow the programmer to
introduce the functionality rather than impose it on him/her.  When
parsing the overall expression in, say,

    \bool_if:nF
      {
        \pbj_is_peanut_butter_jelly_time_p:               % (A)
        &&
        \pbj_can_dance_p:                                 % (B)
        &&
        ! (
            \pbj_has_suit_p:N \g_tmp_person ||            % (C)
            \bool_validate:n % or maybe \bool_eval_all:n
              {
                \token_if_eq_meaning_p:NN #1 ? ||         % (D)
                \token_if_eq_meaning_p:NN #1 !            % (E)
              }
          )
      } { dance ~ like ~ there's ~ no ~ tomorrow }

A and B will short-circuit as they do today.  If A is false, B through
E will not be evaluated.  If A is true and B is false, ... etc.

If ( A && B && !C), we'll get to \bool_validate:n.  This will evaluate
everything in its argument *without* short-circuiting.

I explained that for the sake of clarity, because...

> The cheapest change in terms of amount of code and of
> maintainability is to drop lazy evaluation of boolean expressions.
> This will require changing in minor ways a few packages where lazy
> evaluation of boolean expressions is assumed.

...this is probably the wiser option, on second thought.  Lazy
evaluation could probably be easily implemented on top of a non-lazy
version.  (This would just be an implementation of shunting-yard.)

> Actually, there is currently a mess of code that is only there to
> support lazy evaluation.  If we get rid of lazy evaluation, I strongly
> expect the code underlying boolean expressions to become simpler.

I believe it must by the very nature of the problem.  Lazy evaluation
takes a bit of knowledge about the operators in itself (in addition to
the knowledge needed to actually evaluate the expression).

> In fact, I believe it would be possible to provide a form of lazy
> evaluation when explicitly requested by the programmer.

... I promise, I just read this :) Yes, I agree this would be a good
idea.  We'd get some modularization for free, as well.

----

As long as the ability to short-circuit expressions remains, that's
probably 'good enough'.  (There's a good argument to say 'the simpler,
the better', so removing lazy evaluation from the 'default' behavior
may the the Right thing to do, anyways.)

Thanks for making me think about this again, and sorry it took me so
long to respond!  Your email was buried in short order :(

All the best,
-Sean


On Thu, Jul 23, 2015 at 8:34 PM Bruno Le Floch <blflatex@gmail.com> wrote:

> Hi Sean,
>
> > I don't believe it's out of the question to wrap macro-parameters in some
> > sort of \bool_validate:n (if such a thing doesn't already exist) that
> would
> > run the checks and issue appropriate errors on a case-by-case basis. I
> > believe it's important to assume the programmer knows what he or she is
> > doing and let them account for this themselves. Otherwise, you introduce
> > complexity where none is needed for a large portion of folks.
>
> Can you clarify what your suggested \bool_validate:n is meant to do?
> Your description is too short for me to have any idea what it is.
>
> If we leave things as they are, I am pretty certain that programmers
> will fall into the pitfall of thinking that
>
>     \bool_if:nTF
>       {
>         \token_if_eq_meaning_p:NN #1 ? ||
>         \token_if_eq_meaning_p:NN #1 !
>       }
>
> is safe, even though it will break horribly if `#1` is `(` or `)`
> (technically I haven't tested so perhaps this works by chance).
>
> The reason I am certain of this is that I fell into this trap (before
> I stopped using boolean expressions), even though I was aware of it.
> This is why we need to change something.  The cheapest change in terms
> of amount of code and of maintainability is to drop lazy evaluation of
> boolean expressions.  This will require changing in minor ways a few
> packages where lazy evaluation of boolean expressions is assumed.
>
> > Not to mention that it is just that much more to test and maintain.
>
> Actually, there is currently a mess of code that is only there to
> support lazy evaluation.  If we get rid of lazy evaluation, I strongly
> expect the code underlying boolean expressions to become simpler.
>
> In fact, I believe it would be possible to provide a form of lazy
> evaluation when explicitly requested by the programmer.  Something
> like
>
>     \bool_if:nTF
>       {
>         \tl_if_exist_p:N #1 &&
>         \bool_lazy:n { \tl_if_empty_p:N #1 }
>       }
>
> would do some trickery under the hood to prevent expansion of
> `\tl_if_empty_p:N #1` if `\tl_if_exist_p:N #1` gives the result
> `false`.
>
>
> Regards,
>
> Bruno
>

--94eb2c07a850998443051caf91d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Bruno :)</div><div><br></div><div>Disclaimer: I=
9;ve completely reversed my stance on this. See below.</div><div><br></div>=
<div>&gt; Can you clarify what your suggested \bool_validate:n is meant to =
do?</div><div>&gt; Your description is too short for me to have any idea wh=
at it is.</div><div><br></div><div>\bool_validate:n is just a thought to al=
low the programmer to</div><div>introduce the functionality rather than imp=
ose it on him/her.=C2=A0 When</div><div>parsing the overall expression in, =
say,</div><div><br></div><div>=C2=A0 =C2=A0 \bool_if:nF</div><div>=C2=A0 =
=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 \pbj_is_peanut_butter=
_jelly_time_p: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 % (A)</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &amp;&amp;</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 \pbj_can_dance_p: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 % (B)</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &amp;&amp;</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 ! (</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \pbj_has_sui=
t_p:N \g_tmp_person || =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0% (C)</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \bool_validate:n % or maybe =
\bool_eval_all:n</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \token=
_if_eq_meaning_p:NN #1 ? || =C2=A0 =C2=A0 =C2=A0 =C2=A0 % (D)</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \token_if_eq_meaning_p=
:NN #1 ! =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0% (E)</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 )</div><div>=C2=A0 =C2=A0 =C2=A0 } { dance ~ like ~ there&#39=
;s ~ no ~ tomorrow }</div><div><br></div><div>A and B will short-circuit as=
 they do today.=C2=A0 If A is false, B through</div><div>E will not be eval=
uated.=C2=A0 If A is true and B is false, ... etc.</div><div><br></div><div=
>If ( A &amp;&amp; B &amp;&amp; !C), we&#39;ll get to \bool_validate:n.=C2=
=A0 This will evaluate</div><div>everything in its argument *without* short=
-circuiting.</div><div><br></div><div>I explained that for the sake of clar=
ity, because...</div><div><br></div><div>&gt; The cheapest change in terms =
of amount of code and of</div><div>&gt; maintainability is to drop lazy eva=
luation of boolean expressions.</div><div>&gt; This will require changing i=
n minor ways a few packages where lazy</div><div>&gt; evaluation of boolean=
 expressions is assumed.</div><div><br></div><div>...this is probably the w=
iser option, on second thought.=C2=A0 Lazy</div><div>evaluation could proba=
bly be easily implemented on top of a non-lazy</div><div>version. =C2=A0(Th=
is would just be an implementation of shunting-yard.)</div><div><br></div><=
div>&gt; Actually, there is currently a mess of code that is only there to<=
/div><div>&gt; support lazy evaluation.=C2=A0 If we get rid of lazy evaluat=
ion, I strongly</div><div>&gt; expect the code underlying boolean expressio=
ns to become simpler.</div><div><br></div><div>I believe it must by the ver=
y nature of the problem.=C2=A0 Lazy evaluation</div><div>takes a bit of kno=
wledge about the operators in itself (in addition to</div><div>the knowledg=
e needed to actually evaluate the expression).</div><div><br></div><div>&gt=
; In fact, I believe it would be possible to provide a form of lazy</div><d=
iv>&gt; evaluation when explicitly requested by the programmer.</div><div><=
br></div><div>... I promise, I just read this :) Yes, I agree this would be=
 a good</div><div>idea.=C2=A0 We&#39;d get some modularization for free, as=
 well.</div><div><br></div><div>----</div><div><br></div><div>As long as th=
e ability to short-circuit expressions remains, that&#39;s</div><div>probab=
ly &#39;good enough&#39;. =C2=A0(There&#39;s a good argument to say &#39;th=
e simpler,</div><div>the better&#39;, so removing lazy evaluation from the =
&#39;default&#39; behavior</div><div>may the the Right thing to do, anyways=
.)</div><div><br></div><div>Thanks for making me think about this again, an=
d sorry it took me so</div><div>long to respond!=C2=A0 Your email was burie=
d in short order :(</div><div><br></div><div>All the best,</div><div>-Sean<=
/div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Thu, Jul 23, 2015 at 8:34 PM Bruno Le Floch &lt;<a href=3D"mailto:blflate=
x@gmail.com">blflatex@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hi Sean,<br>
<br>
&gt; I don&#39;t believe it&#39;s out of the question to wrap macro-paramet=
ers in some<br>
&gt; sort of \bool_validate:n (if such a thing doesn&#39;t already exist) t=
hat would<br>
&gt; run the checks and issue appropriate errors on a case-by-case basis. I=
<br>
&gt; believe it&#39;s important to assume the programmer knows what he or s=
he is<br>
&gt; doing and let them account for this themselves. Otherwise, you introdu=
ce<br>
&gt; complexity where none is needed for a large portion of folks.<br>
<br>
Can you clarify what your suggested \bool_validate:n is meant to do?<br>
Your description is too short for me to have any idea what it is.<br>
<br>
If we leave things as they are, I am pretty certain that programmers<br>
will fall into the pitfall of thinking that<br>
<br>
=C2=A0 =C2=A0 \bool_if:nTF<br>
=C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \token_if_eq_meaning_p:NN #1 ? ||<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \token_if_eq_meaning_p:NN #1 !<br>
=C2=A0 =C2=A0 =C2=A0 }<br>
<br>
is safe, even though it will break horribly if `#1` is `(` or `)`<br>
(technically I haven&#39;t tested so perhaps this works by chance).<br>
<br>
The reason I am certain of this is that I fell into this trap (before<br>
I stopped using boolean expressions), even though I was aware of it.<br>
This is why we need to change something.=C2=A0 The cheapest change in terms=
<br>
of amount of code and of maintainability is to drop lazy evaluation of<br>
boolean expressions.=C2=A0 This will require changing in minor ways a few<b=
r>
packages where lazy evaluation of boolean expressions is assumed.<br>
<br>
&gt; Not to mention that it is just that much more to test and maintain.<br=
>
<br>
Actually, there is currently a mess of code that is only there to<br>
support lazy evaluation.=C2=A0 If we get rid of lazy evaluation, I strongly=
<br>
expect the code underlying boolean expressions to become simpler.<br>
<br>
In fact, I believe it would be possible to provide a form of lazy<br>
evaluation when explicitly requested by the programmer.=C2=A0 Something<br>
like<br>
<br>
=C2=A0 =C2=A0 \bool_if:nTF<br>
=C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \tl_if_exist_p:N #1 &amp;&amp;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \bool_lazy:n { \tl_if_empty_p:N #1 }<br>
=C2=A0 =C2=A0 =C2=A0 }<br>
<br>
would do some trickery under the hood to prevent expansion of<br>
`\tl_if_empty_p:N #1` if `\tl_if_exist_p:N #1` gives the result<br>
`false`.<br>
<br>
<br>
Regards,<br>
<br>
Bruno<br>
</blockquote></div>

--94eb2c07a850998443051caf91d1--