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