Is anyone out there using \if_bool:N or \if_predicate:w? No occurrence in TeXlive 2011, and if we switch to Church booleans, those functions would have to go. > Provided it really does not change the interface in any way, there > should no problem with altering the internals. I've been trying to make the change. The end-user interface is not changed, but since booleans become weird beasts (rather than the simple 0/1 switch), they are pretty much impossible to manipulate before the machinery is setup. The problem is then that expl3 and l3bootstrap need to manipulate \l_expl_status_bool very early on. I haven't found a clean way to resolve this issue yet, so I'm a bit stuck. At the end of the day, Church booleans have a definite practical advantage, with non-expandable conditionals in \bool_if:nTF. I'm starting to dislike them, though, from an aestetic point of view, because \char"1 looks nicer than "\marker { \use_i:nn }" (with braces). >> - 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. I've got this pencilled for after some regex fixes/improvements. (Although I first need to get my system back working, as I don't feel like just -reverting- my past few hour's work.) >> - 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. In the process of answering your question, I realize that \bool_if:nTF doesn't like being put in the u-part of an alignment preamble (the part before the cell's contents). Actually, I'm getting very confused about all 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. >> >> 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. A missing xor function is pretty much my only argument here. Although I guess that we could add some ++ or VV or whatever notation is standard for xor. I'll try to understand how robust we can be within alignments. Regards, Bruno