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