LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bruno Le Floch <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 14 Oct 2011 17:42:47 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (46 lines)
There are three completely independent aspects:

- 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.

- 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.

- 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 don't think that we should drop the infix notation. We could provide
optimized \bool_(and|or|not):nn functions for cases where performance
matters, and for those who prefer that prefix notation.

> 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.

The main argument for Church-type booleans is not the speed, but the
fact that they allow non-expandable tests to have a corresponding
predicate.

> 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.

Regards,
Bruno

ATOM RSS1 RSS2