Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p9ELk8pW007239 for ; Fri, 14 Oct 2011 23:46:09 +0200 Received: (qmail 3855 invoked by alias); 14 Oct 2011 21:46:03 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 14 Oct 2011 21:46:02 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx047) with SMTP; 14 Oct 2011 23:46:02 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p9ELh8g7019765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2011 23:43:08 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p9EFoqH3025032; Fri, 14 Oct 2011 23:43:07 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1808175 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 14 Oct 2011 23:43:07 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p9ELh76v000936 for ; Fri, 14 Oct 2011 23:43:07 +0200 Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p9ELh2cd019746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 14 Oct 2011 23:43:05 +0200 Received: by eye3 with SMTP id 3so1946710eye.22 for ; Fri, 14 Oct 2011 14:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.6.25 with SMTP id 25mr6327895fax.14.1318628568211; Fri, 14 Oct 2011 14:42:48 -0700 (PDT) Received: by 10.152.4.193 with HTTP; Fri, 14 Oct 2011 14:42:47 -0700 (PDT) References: <4E95A9C2.6020607@residenset.net> <4E95C086.7060806@morningstar2.co.uk> <4E96F7BF.9070700@residenset.net> <4E97EA81.6040504@morningstar2.co.uk> Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Whitelist: Message-ID: Date: Fri, 14 Oct 2011 17:42:47 -0400 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Bruno Le Floch Subject: Re: Church booleans To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4E97EA81.6040504@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p6sJLDpZh614Kjz2nt6F3tHAKOVebku8MYkQASEEJETQHhiGK1BXJDKCaHSx L7aH9fBEc7VbVGaWW8qeCXrhIKefVw2LzPhYIp81m8V8D4ePFz5MNty03YvnKt+rC7eBbMlcAiqP 5l7aSd0OFncS2le7LpSYUPUqfN8EhQJl1nyqOIXiym8u/v47bukFfirTLc=V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6944 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