## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: Church booleans

From:

Date:

Thu, 13 Oct 2011 14:23:51 -0400

Content-Type:

text/plain

Parts/Attachments:

 text/plain (112 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 tighter? (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 { }, 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{} > > 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{}" to the user quite awkward. -- Bruno