Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
References: <4C967C9B.5010706@gmx.de>                                          
            <71ED7A5B-DE11-45D9-9785-95A1DC795080@gmail.com>                   
            <4C9724B4.3010301@residenset.net>                                  
            <AA223041-D9B8-4EE4-BF8A-5782FAC2078A@gmail.com>                   
            <D6A512C4-5F40-4178-A72F-0D0612DC9A14@gmail.com>                   
            <19607.26705.947540.499705@morse.mittelbach-online.de>             
            <D8A49385-C6F5-4601-97B5-EC2E0501BEF8@gmail.com>                   
            <4C9840AB.4050805@gmx.de>                      
            <732A7500-5414-4818-87E3-33CB14463288@gmail.com>           
            <4C98435A.1050507@gmx.de> <4C989ACB.5060000@morningstar2.co.uk>
            <353AB782-051D-400D-99B4-E3258AAB4F35@gmail.com>
            <4C99044E.8080303@morningstar2.co.uk>
Content-Transfer-Encoding: 8bit
Message-ID:  <5BF5993A-0BC8-4FC1-BD14-2E909DE5BE1F@gmail.com>
Date:         Wed, 22 Sep 2010 12:07:20 +0930
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: boolean expressions in ExplSyntaxNames
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4C99044E.8080303@morningstar2.co.uk>
Precedence: list
Status: R

On 22/09/2010, at 4:45 AM, Joseph Wright wrote:

> On 21/09/2010 14:05, Will Robertson wrote:
>> I'm not willing to throw away the infix notation,
> 
> I'd point out that we have an outstanding bug in the infix system with no obvious solution. For other readers, you'll find that
> 
>  \bool_if_p:n { ! (\c_true_bool)  && \c_false_bool }
> 
> gives the wrong result.

I'd half-forgotten about this, oops.

I've now studied the code and fixed up the problem in a rudimentary way (that's all I'm good for, really). For those who are interested I'll explain my analysis and solution below.

This means I still want the infix notation to stick around, okay? :)
But adding the optimised functional notation definitely seems like a good idea to me, as well.

* * *

The way the boolean infix notation works is all rather neat; a scanner looks ahead at the material to follow and branches accordingly, expanding everything as it goes with \romannumeral. This expanding-as-it-goes is where the problem started. When gathering boolean bits and combining them and expanding, everything works swimmingly with runs like

( 1 && 1 ) || ( 0 || 1 )

as each boolean subexpression can be collapsed linearly. E.g., the above essentially expands to

(1) || ( 0 || 1)
(0 || 1)
(1)

When there are negation symbols around, however, we have to be careful about how and when the logic reversal happens.

The code said something like (don't follow this too closely)

!(...) ->  \expandafter \intexpr_if_even_p:n \number \expandafter \CLEANUP \number \expandafter \SCAN \expandafter \BOOL \romannumeral ...

which all looks like quite a mess (and I possible transcribed it slightly incorrectly), but the gist of the matter is that the \romannumeral expansion ends up "running away" from the \ifodd, which doesn't get expanded until much later at an incorrect time.

Hence explaining why

    !(TRUE)  ||  FALSE

was returning "true": after \romannumeral started inside the parentheses, it didn't stop until after the "|| FALSE" comparison, only after which was the negation applied. You could consider that the || had a higher precedence in this case; it was actually being interpreted as

    ! ((TRUE)||FALSE)

* * *

Well, my solution isn'y very elegant, but according to my tests everything is working correctly. Because of the runaway expansion in the design of the process, I couldn't see a way to limit the grouping of the negation, so I did the only other thing I could think of: invent a new grouping system that reverses its inner logic.

(I tried adding in extra runaway expansion steps earlier in the process, but I didn't have a good handle on the system then and failed quickly. Perhaps there is a much simpler solution to the problem that what I've implemented!)

Previously, |!(...)| expanded to |!| plus the regular code for grouping to process |(...)|, then the result was reversed. Now, the lookahead goes into a different code branch when it sees a group after a negation, and the fundamental logic inside this group is reversed. There is no "extra step" for performing the \intexpr_if_even_p:n reveral, so the logic now groups correctly.

That's the idea, anyway. I've expanded the test suite for the boolean logic (it took me a few goes to get the different reversals correct) and I believe it's all working. But I really have to get some other work done today, so I'll have to stop there.

Please let me know if you see any problems or areas for simplification in the code.

Best regards,
-- Will