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 o8KE14nI026587 for ; Mon, 20 Sep 2010 16:01:05 +0200 Received: (qmail 8706 invoked by alias); 20 Sep 2010 14:00:59 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 20 Sep 2010 14:00:53 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx091) with SMTP; 20 Sep 2010 16:00:53 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id o8KDwXNd028601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Sep 2010 15:58:33 +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 o8KDvhSD012535; Mon, 20 Sep 2010 15:58:26 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 482945 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 20 Sep 2010 15:57:53 +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 o8KDvrAE026466 for ; Mon, 20 Sep 2010 15:57:53 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id o8KDwb0R031852 for ; Mon, 20 Sep 2010 15:58:41 +0200 Received: from morse.mittelbach-online.de (p54A8383C.dip.t-dialin.net [84.168.56.60]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MOTPZ-1OrwEy0cEP-005lAu; Mon, 20 Sep 2010 15:57:41 +0200 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 1E8C563CA8; Mon, 20 Sep 2010 15:57:38 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 References: <4C967C9B.5010706@gmx.de> <71ED7A5B-DE11-45D9-9785-95A1DC795080@gmail.com> <4C9724B4.3010301@residenset.net> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:KzNaBC5ZU5LU/YCaLFQvdFycFNVio+NY7BPf62yQKRK tCPyE73dAUZZDLsHaRvjCVCmt98fyqPDKPWjtnjzyFnMWS0UQn d/gq5oTMakeLPY21UqUfwiOiswpgnCdtLu6LsALimADRJ0LOha Mu2A1nSTjWYYxXLb3Lb2wAFMQ4s3FbQ8PfY9lQGNwiNxp77pYD pAinLhTQAWflI5wcxyd9A== X-Spam-Whitelist-Provider: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id o8KDvrAE026469 Message-ID: <19607.26705.947540.499705@morse.mittelbach-online.de> Date: Mon, 20 Sep 2010 15:57:37 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: boolean expressions in ExplSyntaxNames To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDtMgfETrECMLUO9erHzOJe7j3G660N4yBY6XHH YPYtmQj6mbYUTZ3LnaFANLWrKE7/wIDhnv+VrW0hxOapLRUwuY9oBqo5h+Dh9B42XlFTMTKlXDju GaV8Q==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: 6424 Will Robertson writes: > On 20/09/2010, at 7:58 PM, Will Robertson wrote: > > > On 20/09/2010, at 6:39 PM, Lars Hellström wrote: > > > >> \bool_and_p:nn{}{} > >> \bool_or_p:nn {}{} > >> \bool_and_p:nnn{}{}{} > >> \bool_or_p:nnn {}{}{} > >> ... > >> > >> for as long as one likes to continue that list. > > > > It would be straightforward to add these to the syntax; there's already \bool_not_p:n and \bool_xor_p:nn. > > I've just implemented these "and" and "or" functions (with :nnnn variants > as well); any objections to adding them to the expl3 code? is there actually any need for the :nnn etc versions? I tend to prefer the lisp like versions too ...not because I find them much more readable :-) but because I still have a suspicion that the inline coding has a performance hit (which is most likely not the case as they are coded by Morten, but there you are). Having said that, one more comment, while || and && can be reasonably mixed within conditions it is still true that there is at least one bug in there with regards to combination with negation (see test file m3prg003.lvt at the end) frank