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 p3FL082n005725 for ; Fri, 15 Apr 2011 23:00:09 +0200 Received: (qmail 2667 invoked by alias); 15 Apr 2011 21:00:03 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 15 Apr 2011 21:00:02 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx074) with SMTP; 15 Apr 2011 23:00: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 p3FKw9Ar015297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 22:58:09 +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 p3FDjg5J027596; Fri, 15 Apr 2011 22:58:09 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1231977 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 15 Apr 2011 22:58:09 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p3FKw96v019576 for ; Fri, 15 Apr 2011 22:58:09 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p3FKw4Up018345 for ; Fri, 15 Apr 2011 22:58:07 +0200 Received: from morse.mittelbach-online.de (p54A83DE8.dip.t-dialin.net [84.168.61.232]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MZQZl-1QRh382udB-00LCE3; Fri, 15 Apr 2011 22:58:04 +0200 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id F32EF74E17; Fri, 15 Apr 2011 22:58:00 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4DA5C4E2.8090005@morningstar2.co.uk> <58AFBC3A-4209-4BC0-BB3A-5B14D6B5EFD8@gmail.com> <4DA727A9.2050903@morningstar2.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:eDLsZiUClm1SRKkQZpEU0Ap4MqJ7yeF/JnM9nplY/Gj HOGgSUSYwcC2zeti+A/760RNd+sS6nVLLBmJOHEAIlEdAxVQiy GZu84Fb+CHHgQiKfVnjIsrofe1pnkLnB9etYHafqqirLvlY012 96g7imDqWe0S2q2a92Uh55eOyILga25l+5E0oX1J/3MA+aVE0U YUr2qJOm9b2Gfu8HP+WMg== X-Spam-Whitelist-Provider: Message-ID: <19880.45400.677093.956908@morse.mittelbach-online.de> Date: Fri, 15 Apr 2011 22:58:00 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: The nature of popping from an empty sequence 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 (eXpurgate); Detail=5D7Q89H36p6myV/soHys3aIHfn03H1tOqVW47Sx0xy8XQkVZSLutGy5vGy05gi0DB9kdz SH4wMP4aYlZi4xiAUc72cOze9M+PeAipEkKBiI/oHwrayRh4UzjV5AjAoh76Dlys4bBFcbYy64wv MrDFHqpUFnF8XaRlDIHK1mhU2rie8BjT7LvZNxktGCjrcRD/964uxPCfb8ybLlS2RfT4w==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: 6708 Bruno Le Floch writes: > >> * These should probably be consistent. > >> * I think returning a quark is dangerous in case of sloppy package > >> authors. > > From the seq point of view, I like the idea of \seq_pop:NNF, with a > \seq_pop:NN variant for an expl3-provided error. me to. > For prop, a missing key is more often not an error(?), so perhaps > providing all four \prop_get:NnN(T)(F) variants may make sense. They > would be implemented internally with a quark test on the result of > \prop_get:NnN (very small performance overhead). Then > \prop_if_in:Nn(TF) would be much less useful, since it is just as slow > as \prop_get:NnN(T)(F). oh well, all said by Bruno already ... I wonder if \prop_if_in:Nn(TF) isn't expandable (or rather could be made so, right now it is a protected conditional (for good)). If so then the fact that it is slower would be ok. I haven't tried, but one could probably build an expandable if_in as well - whether that's worth the effort is a differnt matter. Otherwise, if could be implemented by using internally get with some internal variable. In the latter cases it would be equally fast but fairly useless. The only difference being that you don#t have to unnecessarily specify a variable name you aren't using. > > > I find that the quark-based approach is about twice as fast as using > > \prop_if_in:Nn. > > Yes, you end up doing the same work (defining an auxiliary function, > expanding the prop, grabbing delimited arguments) twice. And quark > tests on single tokens are fast. right, that is one of the reasons why they got invented in the first place. frank