User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1)
            Gecko/20110929 Thunderbird/7.0.1
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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E99D8B9.6080302@morningstar2.co.uk>
Date:         Sat, 15 Oct 2011 20:02:17 +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: Re: Church booleans
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <CANQYN6xMzj_NPWzK9iM2Pkk9=OnjRpoqJ-djvq1x0MU1AHvTpQ@mail.gmail.com>
Precedence: list
Status: R

On 14/10/2011 22:42, Bruno Le Floch wrote:
> - Change in the implementation to use Church-like booleans (not quite
> \use_i:nn and \use_ii:nn): this brings in a performance improvement,
> and also allows _if we want_ to have predicates for non-expandable
> tests. Since there is no change in the interface, this can be changed
> at any time.

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

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

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

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