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