On 14/10/2011 22:42, Bruno Le Floch wrote: > - Change in the implementation to use Church-like booleans (not quite > \use_i:nn and \use_ii:nn): this brings in a performance improvement, > and also allows _if we want_ to have predicates for non-expandable > tests. Since there is no change in the interface, this can be changed > at any time. Provided it really does not change the interface in any way, there should no problem with altering the internals. > - Change in the priority of the various operators, to be ! > && > ||. > I believe that this should be changed eventually. It is tricky to get > right, but I can do that in a couple of week if the general feeling is > that we should change. We probably should consider this, as it does seem that this is a general feature of boolean logic. > - Change in the interface to use "not", "and" and "or" instead of "!", > "&&" and "||". I do prefer how boolean expressions look like with "&&" > and "||", but "&" makes our lifes a little bit awkward in alignments > (can be made fully robust, with a performance cost ~10-30%?). I'm intrigued by the 'fully robust' statement here: I've had some problems with \halign's, where if you end up with nested Appendix D tricks then all sorts of trouble starts. >> 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. > > We can support both syntaxes (temporarily or forever) with no > performance cost compared to just "&&" and "||". Dropping "&&" and > "||" in favor of "and " and "or" improves performance a little. > > Switching to "and", "or", "not" raises the question of whether to add > "xor", which is currently missing. That makes priority handling > tougher, so I'm only half keen on that. I don't see why you'd add "and"/"or"/"not" unless the aim was to remove "&&"/"||"/"!". There are places where alternative syntaxes are helpful, but I don't see that here. -- Joseph Wright