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 p8RD444G011504 for ; Tue, 27 Sep 2011 15:04:06 +0200 Received: (qmail 16201 invoked by alias); 27 Sep 2011 13:03:59 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 27 Sep 2011 13:03:59 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx039) with SMTP; 27 Sep 2011 15:03:59 +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 p8RD1kUO008759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Sep 2011 15:01:47 +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 p8RC7P7F001176; Tue, 27 Sep 2011 15:01:46 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1657773 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 27 Sep 2011 15:01:46 +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 p8RD1k1H029497 for ; Tue, 27 Sep 2011 15:01:46 +0200 Received: from ueamailgate02.uea.ac.uk (ueamailgate02.uea.ac.uk [139.222.131.185]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p8RD1Xtn011410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Sep 2011 15:01:38 +0200 Received: from ueams01.uea.ac.uk (ueams01.uea.ac.uk [139.222.131.78]) by ueamailgate02.uea.ac.uk (8.13.8/8.13.8) with ESMTP id p8RD1XE9007568 for ; Tue, 27 Sep 2011 14:01:33 +0100 Received: from [139.222.112.35] by ueams01.uea.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1R8XFY-0002Wh-0c for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 27 Sep 2011 13:59:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 References: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, outgoing) X-CanIt-Geo: ip=139.222.131.78; country=GB; region=I9; city=Norwich; latitude=52.6333; longitude=1.3000; http://maps.google.com/maps?q=52.6333,1.3000&z=6 X-CanItPRO-Stream: UEA:outgoing (inherits from UEA:default,base:default) X-Canit-Stats-ID: 06FBN1x8s - 606e512d71d1 - 20110927 X-Scanned-By: CanIt (www . roaringpenguin . com) on 139.222.131.185 Message-ID: <4E81C92B.8030405@morningstar2.co.uk> Date: Tue, 27 Sep 2011 14:01:31 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Joseph Wright Subject: Re: o and V-type functions 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 (Sender is in whitelist: joseph.wright@MORNINGSTAR2.CO.UK); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnBi0P5cROEGjO+pG7NAH/K+tf9SrVFtpLrKONl 2T9EL4W4U4jgzLbnCcGpk1z/zwmKT/K1fv3lD0=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: 6905 On 27/09/2011 13:10, Ulrike Fischer wrote: > The documentations source3 says at the start "In general, the V and > v specifiers are favoured over o for recovering stored information". > > But everytime I start to define functions which should expand their > argument I end either with x or o types. > > As an example I tried to write a function which process key-val > lists. The list can also be given through a command. With o this > works fine, with V normal and empty lists gives errors: > > \documentclass[parskip]{scrartcl} > \usepackage{expl3} > > > \begin{document} > > \section{expl3} > \ExplSyntaxOn > > \keys_define:nn {test} > {testa .code:n = {#1}, > testb .code:n = {#1}, > } > > > \cs_new:Npn \test_usekeys:n #1 {keys:~[\keys_set:nn {test}{#1}]} > \cs_generate_variant:Nn \test_usekeys:n {V} > \cs_generate_variant:Nn \test_usekeys:n {o} > > \def\mykeylist{testa=A,testb=B} > > \test_usekeys:V {\mykeylist} > %\test_usekeys:V {testa=A,testb=B} > %\test_usekeys:V {} > > \par > > \test_usekeys:o {\mykeylist}\\ > \test_usekeys:o {testa=A,testb=B}\\ > \test_usekeys:o {}\\ > \test_usekeys:o {\mykeylist}\\ > > \end{document} > > > Could someone explain me when arguments of type V are actually > useful and "better" than o and how they should be used? The idea behind the "V" specifier is that it is independent of the implementation of a variable. Over time, we've moved to using macros for most items, but historically there were several toks-based variables where the difference in expansion behaviour was important. We do have register data types for things like dimens, and there there is an advantage to a 'implementation independent' approach: see later. What perhaps we've not made clear is that "V" applies to a _single token_ variable name, while "o" applies to multiple tokens. So "\test_usekeys:V {\mykeylist}" is conceptually wrong (although in this case it will work), and should read "\test_usekeys:V \mykeylist". In cases where you always know that the variable will be macro-based, you can always use "o". However, with "V" it's possible to do something like \my_set_function:V \l_my_clist \my_set_function:V \l_my_int and 'coerce' the int to a clist with one item in it. (I'm using exactly this approach inside xgalley to avoid worrying about complexity in cases where the input might be a list or might be a int.) I did some performance tests, and in general we don't see too much loss in speed using "V" rather than "o". So you can gain the fact that "V" maintains the _semantic" concept of 'pass the variable value', rather than 'expand this token once', without a serious loss of performance. -- Joseph Wright