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 p3N0pF8F023775 for ; Sat, 23 Apr 2011 02:51:16 +0200 Received: (qmail 9990 invoked by alias); 23 Apr 2011 00:51:10 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 23 Apr 2011 00:51:09 -0000 Received: from relay2.uni-heidelberg.de (EHLO relay2.uni-heidelberg.de) [129.206.210.211] by mx0.gmx.net (mx015) with SMTP; 23 Apr 2011 02:51:09 +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 p3N0mAuG015413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Apr 2011 02:48:11 +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 p3MM15CA016433; Sat, 23 Apr 2011 02:48:10 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1207030 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 23 Apr 2011 02:48:10 +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 p3N0mAk1027467 for ; Sat, 23 Apr 2011 02:48:10 +0200 Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.213.177]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p3N0m3VU031398 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 23 Apr 2011 02:48:09 +0200 Received: by yxh35 with SMTP id 35so386716yxh.22 for ; Fri, 22 Apr 2011 17:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.26.34 with SMTP id b22mr1714815yha.201.1303519683539; Fri, 22 Apr 2011 17:48:03 -0700 (PDT) Received: by 10.147.136.4 with HTTP; Fri, 22 Apr 2011 17:48:03 -0700 (PDT) References: <4DAFEC37.9070505@morningstar2.co.uk> Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Whitelist: Message-ID: Date: Fri, 22 Apr 2011 20:48:03 -0400 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Bruno Le Floch Subject: Re: Efficiency v correctness in \cs_new:Npn To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4DAFEC37.9070505@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p4yCuwxJv6KY0FCZRnwZ+13Up+PAlfdmTtY6x+eAfghfrIJaOOSN8fl2u7an XR4GlybSDcAM+gPFjF9C5ofgQZYQfbcMoQwkkprUeTtnBQj34tzweG+MzCQpJGThDIxgC9bTm74P csOBzyhDVm3KJCHbyAVDXTLtDy354ZZYFriFlQ29vRw/zxlDS4uHOi6+qbYVdhrK5JvdA==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: 6723 On 4/21/11, Joseph Wright wrote: > On 21/04/2011 09:27, Will Robertson wrote: >> Hi, >> >> Bruno has raised an issue [1] with \cs_new:Npn: it's slow. >> >> [1]: http://github.com/latex3/svn-mirror/issues/17 >> >> Around the time when the "\cs_" prefix was first introduced, Morten added >> a check to \cs_new:Npn to ensure you weren't trying to use it to define a >> command with a ":D" suffix, as they should be reserved for engine >> primitives. >> >> This seemed like a good idea at the time, but considering how often >> \cs_new:Npn is used in expl3, it has a definite performance hit to >> performing this check each and every time it's used. >> >> We'd like to propose dropping this check and moving it into the currently >> defunct l3chk module, which is designed to "switch on" these optional >> checks that are nice in theory but not efficient in practise. (l3chk >> hasn't been maintained so much but at some point I'd like to revive it.) >> >> Any thoughts for or against this idea? > > I am in favour of this: checking for 'free' functions should really just > do that (after all, there are _lots_ of other mistakes that could be > made that are not checked). > > On the l3chk module, I think it is clear we need to overhaul the > 'checking' guards and so forth for a 'slower but more careful' version > of expl3 for debugging. This check would fit in there, I guess. Additionnal check that l3chk could perform (but should be disablable): that the module only defines functions which belongs to it (i.e. the part before the first "_" is good), with perhaps something to declare what namespace the programmer wants to use. Regards, Bruno