LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Thu, 13 Oct 2011 14:23:51 -0400
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=ISO-8859-1
Bruno Le Floch <[log in to unmask]>
text/plain (113 lines)
For those not willing to read until the end, the two questions which matter are

(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

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

> My first impulse to a response to that question was "That's a strange
> expression, maybe there's a typo? But as written, I would code that as
>    \and:nnnTF{\l_my_first_bool}{\l_my_second_bool}
>       {\not:nTF{\l_my_third_bool}}
> " But I gather from the subsequent discussion that you're asking about the
> possibilities for using infix notation operations on Church booleans.

Yes. See my last email, where I provide a variation on your idea where
the infix notation works.
The main problem is that we are not only manipulating booleans, but
_predicates_, which take arguments. Thus my approach of making
predicates expand to { <code which has grabbed its arguments> }, with
the extra braces. Then everything else is a matter of getting the
logic right.

>    \bool_if:nTF { \bool_pred:n{\l_my_first_bool} &&
>     ( \bool_pred:n{\l_my_second_bool} && !\bool_pred:n{\l_my_third_bool} ) }

That's unreadable. :)

> Whether whatever scheme you're currently using to parse these expressions
> could be taught to insert the \bool_pred:n (or just \c_true_bool
> \c_false_bool) automatically is of course another matter.

That's not possible with e.g., \str_if_eq_p:xx {a} {a} if it is
exactly the same as \str_if_eq:xxTF{a}{a}, because we never know how
many arguments the predicate takes. With the extra pair of braces as
proposed in my previous mail, things can be made to work (and fast).

> Guilty as charged. However, the foreign syntax thing is more of an analytic
> criticism that came at second or third thought. First I had been scared by
> seeing & used for something that had nothing to do with alignments, and
> annoyed by realising that it did not give different priorities to && and ||
> (thus seeming to promise a feature that it actually didn't deliver).
> \if_bool:nTF may subsequently have been improved in the latter respect.

Should && have higher or lower priority than || ? Is there an accepted standard?
Currently, in "a XX b YY c ZZ d", the right-most operator, "ZZ" has
highest priority, then "YY", then "XX". In python it seems to be that
"and" has higher precedence than "or".

> Another thing about the Church booleans is that they do not require a
> framework to be useable; they can be used directly also in code written with
> \ExplSyntaxOff.

I don't see how you could use \l_my_church_bool (or any other
predicate) without \ExplSyntaxOn.

> I can see that becoming convenient every now and then, for
> document preamble command definitions (even though there arguably has to be
> a leaky abstraction somewhere for them to even become exposed, such things
> will happen).

Just like document preambles often need \makeat(letter|other), they
could use \ExplSyntax(On|Off) if needed. If the issue is with
preserving spaces, then \ExplNames(On|Off) is also provided, and
(infix) boolean expressions work there as well.

We could provide \bool_and:nn etc. (or some variation thereof). One
problem is where to stop: here you've used the three argument variant
\add:nnn, but we should then provide a four argument variant, etc.
Hence the input should be some kind of list, which ( a && b && c &&
... && d ) is. It is rather unfortunate indeed that & has to be used
there: its catcode leads to trouble. I don't see what other character
could reasonably be used, unless we go for "and" and "or" (that would
be just as fast to parse).

On a separate point: we haven't provided things like \int_add:nn or
\int_mul:nn as a prefix replacement for + or * in \int_eval:n (eTeX's
\numexpr), because that doesn't improve legibility. I find that the
current \bool_if:nTF with infix operators (except \xor) fits nicely
with the syntax of \int_eval:n, \dim_eval:n, and a future \fp_eval:n.

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