MIME-Version: 1.0
References: <4E95A9C2.6020607@residenset.net>
            <4E95C086.7060806@morningstar2.co.uk>
            <CANQYN6yk7B1Vuv+KMp6YdRt768-SHzqwNEsptO-9toVrnx+5dQ@mail.gmail.com> <4E96F7BF.9070700@residenset.net>
            <CANQYN6x2jV8b1WPre4U0G3wq0aKc7zLUka7vD6rJWKNMMapEJg@mail.gmail.com> <4E97EA81.6040504@morningstar2.co.uk>
            <CANQYN6xMzj_NPWzK9iM2Pkk9=OnjRpoqJ-djvq1x0MU1AHvTpQ@mail.gmail.com>
            <4E99D8B9.6080302@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6z6z+vQ+MnZW8bMtzpsdkKfO0TujkpJXk9-xkw+Y4FB-w@mail.gmail.com>
Date:         Sat, 15 Oct 2011 21:55:18 -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: Church booleans
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4E99D8B9.6080302@morningstar2.co.uk>
Precedence: list
Status: R

Is anyone out there using \if_bool:N or \if_predicate:w? No occurrence
in TeXlive 2011, and if we switch to Church booleans, those functions
would have to go.

> Provided it really does not change the interface in any way, there
> should no problem with altering the internals.

I've been trying to make the change. The end-user interface is not
changed, but since booleans become weird beasts (rather than the
simple 0/1 switch), they are pretty much impossible to manipulate
before the machinery is setup. The problem is then that expl3 and
l3bootstrap need to manipulate \l_expl_status_bool very early on. I
haven't found a clean way to resolve this issue yet, so I'm a bit
stuck.

At the end of the day, Church booleans have a definite practical
advantage, with non-expandable conditionals in \bool_if:nTF. I'm
starting to dislike them, though, from an aestetic point of view,
because \char"1 looks nicer than "\marker { \use_i:nn }" (with
braces).

>> - Change in the priority of the various operators, to be ! > && > ||.
>> I believe that this should be changed eventually. It is tricky to get
>> right, but I can do that in a couple of week if the general feeling is
>> that we should change.
>
> We probably should consider this, as it does seem that this is a general
> feature of boolean logic.

I've got this pencilled for after some regex fixes/improvements.
(Although I first need to get my system back working, as I don't feel
like just -reverting- my past few hour's work.)

>> - Change in the interface to use "not", "and" and "or" instead of "!",
>> "&&" and "||". I do prefer how boolean expressions look like with "&&"
>> and "||", but "&" makes our lifes a little bit awkward in alignments
>> (can be made fully robust, with a performance cost ~10-30%?).
>
> I'm intrigued by the 'fully robust' statement here: I've had some
> problems with \halign's, where if you end up with nested Appendix D
> tricks then all sorts of trouble starts.

In the process of answering your question, I realize that \bool_if:nTF
doesn't like being put in the u-part of an alignment preamble (the
part before the cell's contents). Actually, I'm getting very confused
about all that :(.

>>> etoolbox goes with the simple "and", "not" and "or", and to me this
>>> seems like a sensible approach. If that is done, there would need to be
>>> transitional support for the current syntax, of course.
>>
>> We can support both syntaxes (temporarily or forever) with no
>> performance cost compared to just "&&" and "||". Dropping "&&" and
>> "||" in favor of "and " and "or" improves performance a little.
>>
>> Switching to "and", "or", "not" raises the question of whether to add
>> "xor", which is currently missing. That makes priority handling
>> tougher, so I'm only half keen on that.
>
> I don't see why you'd add "and"/"or"/"not" unless the aim was to remove
> "&&"/"||"/"!". There are places where alternative syntaxes are helpful,
> but I don't see that here.

A missing xor function is pretty much my only argument here. Although
I guess that we could add some ++ or VV or whatever notation is
standard for xor.

I'll try to understand how robust we can be within alignments.

Regards,
Bruno