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 p8JACH52001366 for ; Mon, 19 Sep 2011 12:12:18 +0200 Received: (qmail 5550 invoked by alias); 19 Sep 2011 10:12:12 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 19 Sep 2011 10:12:11 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx093) with SMTP; 19 Sep 2011 12:12:11 +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 p8JA9br9013366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2011 12:09:38 +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 p8JA5Obc018389; Mon, 19 Sep 2011 12:09:36 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1602641 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 19 Sep 2011 12:09:36 +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 p8JA9aNp024755 for ; Mon, 19 Sep 2011 12:09:36 +0200 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id p8JA9N5x011077 for ; Mon, 19 Sep 2011 12:09:27 +0200 Received: from mittelbach-online.de (p3EE3ECA0.dip.t-dialin.net [62.227.236.160]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MXFZN-1QZVBP4BE5-00VuBn; Mon, 19 Sep 2011 12:09:23 +0200 Received: by mittelbach-online.de (Postfix, from userid 783) id A212D1F40203; Mon, 19 Sep 2011 12:09:18 +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.104]) (Authenticated sender: frank) by mittelbach-online.de (Postfix) with ESMTPSA id A81021F40203 for ; Mon, 19 Sep 2011 12:09:16 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 110919-0, 19.09.2011), Outbound message X-Antivirus-Status: Clean X-Provags-ID: V02:K0:YjNqWdTrxmM0Vg0CutscZ74pGa8JKSfW1BBejaqgUO6 9//8Ifun6yjfV3XGiKYj3W18luh4GT5k9opCGaSKzAfab4Nynv XVhQBBiFl0M0/edJd8XhL485crSubOzYOnEQEr6XXQF41aMAPa CYLDT7bpnSM60NcZTqKg/6wbXyjorZsoNgqBIfhUTrU9erDLjz K7c9/GOydeBgUeYEZCPzqFDc8zst9Uvl7c09XMmJPopsiB+0To yFgsJM8CUNY1bbe3XLyUfK5sIpN6PnBsyNGQsXzAj40wZNHiOO sluX8iPR4desKuVGQAaEvboLfsA6wNLkU+PmE29nKDLT2qhTbm +1qABivouTjoYsSXybr4nZsOm5jS08yiuBAiVupMb Message-ID: <4E7714CB.7060408@latex-project.org> Date: Mon, 19 Sep 2011 12:09:15 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Removal of previously-notified functions To: LATEX-L@listserv.uni-heidelberg.de Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (eXpurgate); Detail=5D7Q89H36p7zYQev1Bv5lawyulDRL8ctTdrFw2SJQ2xoFInGLHjqhMQPpt9ZNFKMUSp3n +zFl48Wz7VG79ezl+eyeseQdOXZx4354iW5J7037W1qKxX/ygpkox5mQJbfVl6YvBDn1+QuM7kY9 gaX2apJqgmsTWdNQL496L2i6i+gTEB0yW22JZD2oW0szAvxIlv+G8bg5O8=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: 6879 Am 18.09.2011 15:47, schrieb Joseph Wright: > On 18/09/2011 10:53, Philipp Stephani wrote: >>> Part of the reasoning we had here is that \tl_new:Nn was being used >>> almost entirely for declaring constants. We have a conceptually-separate >>> \tl_const:Nn for that job. >> >> I think both make sense, just like in other programming languages, >> where you have e.g. "const int x = ..." as well as "int x = ...". > > This very much depends on the other languages you are used to. Like > Will, I guess I prefer the separate 'declare' and 'assign' operations. well, I used \tl_new:Nn quite a lot and had to get used to not doing so Fact is with all (!) variables you do not only declare them in TeX you always also assign a value to them (which in case of tl is "empty" in case of "int" is zero etc). Not in all cases this default value is the right one and even without wanting to make a constant you might want the initial value of an integer be 1 or what have you. But the number of cases where this is useful is limited. In many cases when used the reason is to set up defaults (that can be overwritten by the user or by somebody) at a later stage through some defined interface. In that case it is usually better to use that interface to also set the defaults -- that is not the style 2e packages where done but once you get the hang of it the number of stray assignments of that sort typically vanish. On the whole I don't mind so much (and as I said I initially started with providing the _new:Nn version at least for tl or as they where called tlp back then). But one thing I would like to have is consistency, ie either for all variable types or for none. However there are a couple of issues here (which is why I think we are better off with the clear separation we have now): - _new:N is used both for local and global variables (as the declaration of variables is always global - _new:Nn would need to come in two flavors one for local one for global assignments. And no we wouldn't want to deduce it from the variable name. Or it could be offered only for local assignments (the way I think it was initially when \tlp_new:Nn existed) - there is the question of the more complex data types where it is fairly obvious that separation of declaration and assignment is better separated So taking all this together I think we should stay as we are now with a fairly clean concepts on function names per data type etc. ====================================== >>>> Also a \cs_new:N command is missing which reserves a "function" name >>>> without assigning it. interesting point. Initially one could argue that this is inconsistent with the idea that we separate declaration and setting of variables. But then this means we understand functions as being data and while in TeX this is certainly true we have gone a long way in expl3 try go away from this notion. As Joseph mentioned standard "functions" in expl3, eg those with :nn etc, are supposed to have a well defined interface of arguments that does *not* change (even if technically nobody would prevent you from doing so). So my question here is: are you perhaps misusing the concepts here? Granted that there are cases where you want to redefine functions to have different args in different situations but they are rare. So I guess it would be interesting to see in which circumstances you think this type of initial declaration would be useful The most often needed cases are are defs to hold data without arguments and for that we have our own data structure in expl3, ie. tl. And in the other cases it is still better to to have the right signature up front, e.g., define \cs_new:Npn \foo:nn #1#2 {} That couldn't be done with a single \cs_new:N unless it would deduce the args from the function name (which, while possible looks like a huge overkill) cheers frank