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 q8D75mKi007388 for ; Thu, 13 Sep 2012 09:05:49 +0200 Received: (qmail 15563 invoked by alias); 13 Sep 2012 07:05:43 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 13 Sep 2012 07:05:42 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx006) with SMTP; 13 Sep 2012 09:05:42 +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 q8D73hMq031431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2012 09:03:43 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.1) with ESMTP id q8D6YQYn007582; Thu, 13 Sep 2012 09:03:43 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 3067888 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 13 Sep 2012 09:03:43 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.1) with ESMTP id q8D73htl015601 for ; Thu, 13 Sep 2012 09:03:43 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id q8D72m63031129 for ; Thu, 13 Sep 2012 09:02:50 +0200 Received: from mittelbach-online.de (p4FEE528C.dip.t-dialin.net [79.238.82.140]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LzlaB-1TYJSt1R6R-0154WZ; Thu, 13 Sep 2012 09:02:48 +0200 Received: by mittelbach-online.de (Postfix, from userid 783) id 9137732A0003; Thu, 13 Sep 2012 09:02:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on Marlowe X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=unavailable version=3.2.5 Received: from [127.0.0.1] (unknown [192.168.123.100]) (Authenticated sender: frank) by mittelbach-online.de (Postfix) with ESMTPSA id 7614A32A0001 for ; Thu, 13 Sep 2012 09:02:22 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 References: <505141C9.60900@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120912-1, 12.09.2012), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V02:K0:29kgzwC58RhmE8d0ic66quZVFtnCovIO7Ch4ZxX5qY8 tDUhS+Udhkg8NgmB1cesRrZNAmRraD5Vv8uQwOjKa8Uus3YIBe n7IGhJqPt26HvD1WQdX38pwqZJx6Xfv26w7Duh3gQjfVceYzfi pwrPP9TH5LB5qCEes1KYubcbbdx8ityxSQcH/+wQm1jhwJ+TP6 ln9LuU2OjtJTROMFyeTrsFNfWIMlhc0ehKJxpJfiURrRxl0wuz Udh1TkAeKqqYDtmjuIiEW1U6N4XXrH/1ghilxriuXPnC7gjSbO 0hg4vUXxTLJToNP6vKR9Kh8wfRP2oFQxdL7OLw26AO1CwEMYQC AN1j5hS664B9qB4F+iJ0WDqBFmx4L+WLTbxrgRLb0 Message-ID: <50518513.30208@latex-project.org> Date: Thu, 13 Sep 2012 09:02:43 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: New auxiliary functions guidelines To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <505141C9.60900@gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p5x1RWm4Ldx8pHNe5ytInNc/kid7nQ6P59hHPwHIR93ijpIBxON66SH4PzOz xN0VkF77IWtOtVbSYce5yxSAKrdQ5R/aIRP22I5QkV0si4PLQ+Tg+29Bx/4rJ1moGkOpnFIMMzrX JrtgSMepWA/AWG893HJfpJsKlrS86gaxosgh3Y3WBiwg2un3gK/FMQLzDw=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: 7151 Am 13.09.2012 04:15, schrieb Joel C. Salomon: > The use of `\@@_function:nn` implies that the initial function is itself > an internal one. Sometime that will be the case, of course, but I think > `\pkg_function:nn` would make a better primary. > > (Thinking aloud: Unless the intention is that `\pkg_function:nn` is the > primary and `\@@_function:nn` ==> `\__pkg_function:nn` is the first > auxiliary? but then you'd have said that.) I think you are right and the intention is not yet properly described. My nomenclature would be something like this: \pkg_function:... is an interface function of the package to the outside world, eg what other packages should use and should be able to rely on. \__pkg_function:... aka \@@_function:... for short is an "internal" package function that is used within the package but shouldn't be used outside and its implementation and semantics are not to be relied on by anybody Now sometimes one has a need for helper functions that are only be used once to implement an internal function, typically when doing some complicated token parsing. Those functions are the one we call "auxiliary" functions and if they are needed they get the string "_aux" in the name. So \@@_function:... is the internal one \@@_function_aux:... is used to implement just the \@@_function:... if more than one "auxiliary is needed for implementing a single function then either they are distinguished by the arg signature or by "_auxi" "_auxii" etc. point is that the "_aux" are intended to help just with a *single* command implementation. If it turns out that one reuses an "_aux" function several times, it would be better to give it a separate descriptive name and make it an internal function and not an auxiliary. perhaps I should also mention that (though not that likely) you may also have the situation that an interface function needs an auxiliary, eg \pkg_function:... \@@_function_aux:... frank