MIME-Version: 1.0
References: <55DBB7F6.1070307@clear.net.nz>
            <55DABA1D.3050706@morningstar2.co.uk>
            <55DCFDF7.7080305@clear.net.nz>
            <55DC05BF.1040505@morningstar2.co.uk>
            <55DC28E8.9090405@morningstar2.co.uk>
            <55DDFD0A.4000901@clear.net.nz>
            <CANQYN6wzPW4aeO0WftqthfZ_6szd6-E60OzGhZcZ1g6JM6rseg@mail.gmail.com> <55DDACCB.1070104@morningstar2.co.uk>
            <55DF523F.2050905@clear.net.nz>
            <CANQYN6zrXjg70uJaw4dEd+_Adye0KHU90dYVmRqpR8CpiOp0_g@mail.gmail.com> <55DF48BE.5030503@residenset.net>
            <55DF5276.7010500@morningstar2.co.uk>
            <55DF70B2.1090700@morningstar2.co.uk>
            <55E09AA8.6070100@residenset.net>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6xAa8TX+p6kvAKk+dvNjMneL9=PhGQebcvDa+P3izkVUg@mail.gmail.com>
Date:         Fri, 28 Aug 2015 23:26:22 +0200
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: Catcode changes
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <55E09AA8.6070100@residenset.net>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

>>> We do the same in xparse :-)
>
> Are you saying xparse handles _matching_ of _nested_ parentheses? Because
> that is what I meant that I demonstrated. Using delimited arguments to grab
> parentheses without considering how they match against each other is of
> course a triviality, but also not useful for the problem considered.

Joseph understood your point perfectly well.  Xparse takes care of
matching nested parentheses, and does that expandably too.  It would
be possible for Andrew to abuse xparse to grab his parenthesized
group, but I am not sure whether I want to advise this or not.  It
would also be possible to simply copy the code, but finding out where
this is done in xparse's code is non-trivial.  I could also just
provide code that does that, but it would take 30 minutes to get
completely right and clean (the code needs to carefully preserve
braces when grabbing delimited arguments, for instance).  Using
\tl_set_rescan:Nnn seems reasonable given the above.

>>>> PS: I maintain that that approach to evaluating infix boolean
>>>> expressions is far superior to what is currently offered in LaTeX3, but
>>>> Bruno just seems to *love* his&&, with all its shortcomings. ;-)
>>>
>>> Will remind myself: as has been noted there is an issue with clearing up
>>> certain tokens with the current lazy evaluation method.
>
> More fundamentally, I believe it only supports expandable tests. There is no
>
> need for a boolean evaluation logic to require tests to be expandable (and
> nor does the logic itself need to be non-expandable).

That is correct.  We had internal discussions at some points and some
people in the team felt that it was useful to know that boolean
expressions were always expandable, hence that the lack of predicates
for protected tests was a feature.  This may have changed since.

>> BTW, thread you mean starts
>>
>>    http://article.gmane.org/gmane.comp.tex.latex.latex3/2719
>>
>> I think the one you mean is
>>
>>    http://article.gmane.org/gmane.comp.tex.latex.latex3/2754
>
> Ah, that is correct.

The main reason I didn't get back to those ideas of yours were lack of
time at the time, not lack of interest.

>> P.S. Boolean expressions are Morten's code, not Bruno's :-)
>
> Oh? I seem to recall Bruno posted repeatedly on it this summer, giving the
> appearance that he was actively working on precisely that code. My bad, in
> that case.

I have indeed posted about that topic because lazy evaluation causes
problems when the arguments of a predicates contain parentheses.  Your
approach (replacing && by and, || by or, and parsing using delimited
arguments) does not solve that, nor can any approach where parentheses
have a syntactic role while also being able to appear as unbraced
arguments to predicates.  E.g.,

   ( \c_false_bool && \token_if_eq_meaning_p:NN ) ( )

will typically not be parsed correctly if any attempt is made to do
lazy evaluation and jump from && (or "and" in your syntax) to a
following ")".  There are rare cases where the current LaTeX3 approach
will work and an approach using delimited arguments will not.

Bruno