Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 17:09:51 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lBAG9khn013330 for ; Mon, 10 Dec 2007 17:09:46 +0100 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 lBAG2cKi008131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 17:02:38 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lBADfe1K008751; Mon, 10 Dec 2007 17:02:19 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 217902 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 10 Dec 2007 17:02:19 +0100 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 lBAG2J2J005962 for ; Mon, 10 Dec 2007 17:02:19 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id lBAG2Ent006734 for ; Mon, 10 Dec 2007 17:02:19 +0100 Received: from morse.mittelbach-online.de (p54A98902.dip0.t-ipconnect.de [84.169.137.2]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1J1l592pIX-0002iO; Mon, 10 Dec 2007 17:02:11 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 0ECC861758; Mon, 10 Dec 2007 17:02:11 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 References: <87k5nxw76i.fsf@buckbeak.hogwarts> <87tzmwkdnr.fsf@buckbeak.hogwarts> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX19VD19AB3GbMIr/WAZStaCbQiO5WSqLq3M3+qA LhXdIHzwtLKNBDtszI3oRv46KY2IusUa9SL2FEuzUIC7VK5kdb l8g0e0zKrezebkFoVHMU4p6okCRu75r X-Spam-Whitelist-Provider: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id lBAG2J2J005963 Message-ID: <18269.25346.697845.365250@morse.mittelbach-online.de> Date: Mon, 10 Dec 2007 17:02:10 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Misleading cs names? To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.464 () BAYES_00,FORGED_RCVD_HELO,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.57 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 10 Dec 2007 16:09:51.0945 (UTC) FILETIME=[187A6390:01C83B47] Status: R X-Status: X-Keywords: X-UID: 5112 Morten Høgholm writes: > On Sun, 09 Dec 2007 22:33:12 +0100, Lars Hellström wrote: > > Hi Lars, > > > 9 dec 2007 kl. 20.14 skrev Morten Høgholm: > >> > >> So perhaps an alternative could be to use something like > >> \int_set:Nr {expression}% r for register? > >> > >> Opinions? > > > > How would such an r be different from x? > > Technically there wouldn't be any difference of course. Only the > implication that everywhere else, x means there is also an n base > function, which is also more or less why I chose the n form initially. and with good reason I think. Let us step back and reevaluate what the arg forms are supposed to mean: \foo:abc % abc are placeholders for real arg specifiers is intended to be a short form for saying - do "a" with the first argument do "b" with the second and do "c" with the third argument prior to passing the argument values to the base function \foo:nnn - it is really only a short form of \exp_args:Nabc \foo:nnn It makes no statements about what \foo:nnn does with the arguments it receives. Some people have suggested we shouldn't provide the short forms, though I feel that they make life much easier once you get the hang of it, but in any case they are only shorts for "manipulate some arguments prior to passing them to a function" There is a bit of inconsistency here in that something like T F are arg specifiers that give information about the argument purpose rather than about a manipulation of the argument and perhaps some of the concepts should be reviewed and unified -- but the direction should be less arg specifiers not more frank