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 p267ntMv015872 for ; Sun, 6 Mar 2011 08:49:57 +0100 Received: (qmail 12565 invoked by alias); 6 Mar 2011 07:49:50 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 06 Mar 2011 07:49:50 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx032) with SMTP; 06 Mar 2011 08:49:50 +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 p267lY0U029168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2011 08:47:34 +0100 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 p25N143r025519; Sun, 6 Mar 2011 08:47:33 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1206144 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 6 Mar 2011 08:47:33 +0100 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 p267lXcN011752 for ; Sun, 6 Mar 2011 08:47:33 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p267lTDG000408 for ; Sun, 6 Mar 2011 08:47:32 +0100 Received: from morse.mittelbach-online.de (p54A83C8F.dip.t-dialin.net [84.168.60.143]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lx5jt-1Q2bzV2ogL-016OxF; Sun, 06 Mar 2011 08:47:28 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id A31A26E76B; Sun, 6 Mar 2011 08:47:25 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4D731368.1060701@gmx.de> <4D7335FC.3050007@morningstar2.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:O1qSMaRw5ArMBmeG397mELHxBZ/SXxjLC6QQxDC0LmU /dT7WqJdPurpU6pzeytMv8mLQpii8iYOAtKuFx+fiC20gWNuFS TJFQcAaPS4qyV4TxIP2WyqCHtPS7FzzLIbit9ycTwVoxvMfOxj Ey0zqAeLAkQpNZDBG9jsHpR2TX6v6z+OWl0KFO0FQevhAQyUlZ gDqcIDTU86Hrs6nNXCWlA== X-Spam-Whitelist-Provider: Message-ID: <19827.15373.437917.416434@morse.mittelbach-online.de> Date: Sun, 6 Mar 2011 08:47:25 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: \coffin_new:c ? To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4D7335FC.3050007@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p4U4jfdfC5HDevlx1X2sAZgP9e9F2VTUYI/FLDAh5vXTVin+wznIYULO4W8f iu4UIHVeutAdNYNyhIIRpjhB4NMqCt7OvFNAZ1Wfx4FZJc627ijqKNPBMry42D3C0vBPyK5et6Ko fYsJQ==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: 6629 Joseph Wright writes: > On 06/03/2011 04:54, Arno Trautmann wrote: > > Hi all, > > > > maybe a stupid question, but is there a reason that there are no > > variants for the coffin functions like the :c type? > > I want to make use of a counter in coffins names, and :c would make life > > much more easier than using \expandafter. Or is there another, yet more > > elegant way to use a counter in the macro name? > > > > cheers > > Arno > > It's not 100 clear yet, but the initial plan at least for me is that > coffins are a design-level construct. That means that \NewCoffin is the > way to produce coffins - \coffin_new:N is there mainly to be wrapped up > in a design-level function. > > Perhaps you might illustrate what you're doing at a 'concept' level? in my opinion it should be there, so I would call it an oversight. On document level, you are right, \NewCoffin should be enough but if you build a package that involves coffins it is possible that the names of that coffin are build from other structures, so that you wan to use :c to produce them But one general comment here Arno: the expl language and its arg "preprocessing" concept was explicitly designed so that any variant from a base function could be added by any package if necessary. So there is never ever a need to use \exp_after:wN. Instead, if you miss a variant you simply provide it via \cs_generate_variant:Nn \coffin_new:N { c } Have a look at the discussion in l3expan.dtx Especially with functions that have many arguments we often only provide a few variants that we forsee to be generally useful. Over time, missing variants, if they turn out to be needed more often, can always be moved to the kernel at some point. Executing \cs_generate_variant:Nn is very light-weight, so it doesn't hurt much if several packages provide the same variant frank