User-Agent: Mozilla/5.0 (Windows NT 6.1; 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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E97EA81.6040504@morningstar2.co.uk>
Date:         Fri, 14 Oct 2011 08:53:37 +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:  <CANQYN6x2jV8b1WPre4U0G3wq0aKc7zLUka7vD6rJWKNMMapEJg@mail.gmail.com>
Precedence: list
Status: R

On 13/10/2011 19:23, Bruno Le Floch wrote:
> (1) Precedence:
> - Currently "a&&b||c" means "a&&(b||c)" and "a||b&&c" means "a||(b&&c)".
> - Other programming languages decide that either && or || has higher
> precedence. Is there an accepted consensus on which one should bound
> tighter?

As other comment, the usual order is NOT > AND > OR (not sure about XOR).

> (2) Using & is awkward. Currently we use "&&" and "||". We could use
> "and" and "or" (and add things like "xor"), with precisely the same
> parsing mechanism, avoiding issues within alignments entirely. It is
> also rather cheap to provide "AND" and "OR", or ".and." and ".or.", or
> whatever else we wish. We just have to decide which one is good (or
> provide several).

Remember that any change here is going to need a *good* reason: change
'for the sake of it' is not what is needed. Now, I've worried before
about using "&", and there are performance arguments for the suggested
Church-type booleans, so there is a case for change. I note 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.

>> Along that line of though, I've also toyed with the idea of having an xparse
>> o argument return either
>>
>>      \NoValue       or
>>      \YesValue{<argument>}
>>
>> where
>>
>> \cs_new:Npn \NoValue {-NoValue-}
>> \cs_new_eq:NN \YesValue \use_i:n
>> \cs_new:Npn \IfNoValueTF #1 { \use_iii:nnn #1 \use_iii:nnn \use_i:nn }
>>
>> It's not quite as elegant as the Church booleans, but strikingly simple.
> 
> And much faster, indeed, than \pdfstrcmp. This would usually get my
> vote. However, xparse is at the user level, so a few micro-seconds
> gained here and there (that's what \benchmark:n is giving me) are not
> going to make any sizeable difference. Also, I find giving the
> arguments as "\YesValue{<argument>}" to the user quite awkward.

Not keen. The \IfNoValue test is supposed to be implemented in exactly
the same way as any other conditional, which the above certainly is not.
Moreover, the above is adding a token (and I guess braces) to the input.
There is no requirement to use a NoValue test with an optional argument,
and the above would therefore mess up any 'direct' use of the input
unless it's being expanded first. You then need to remember that part of
the defined semantics of \NoValue is that its protected, so it's not
clear what should happen about protection for \YesValue.

As Bruno comments, performance at the user end is not critical. I'm not
sure that this change really offers a benefit which justifies some
potentially-risky alterations.
--
Joseph Wright