Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Dec 2007 20:19:28 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lB9JJMWF012949 for ; Sun, 9 Dec 2007 20:19:22 +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 lB9JF1Y6028628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Dec 2007 20:15:02 +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 lB8N172s007561; Sun, 9 Dec 2007 20:14:50 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 209492 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 9 Dec 2007 20:14:50 +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 lB9JEod4002783 for ; Sun, 9 Dec 2007 20:14:50 +0100 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lB9JCZrF014052 for ; Sun, 9 Dec 2007 20:12:40 +0100 Received: by py-out-1112.google.com with SMTP id u52so3134446pyb for ; Sun, 09 Dec 2007 11:14:36 -0800 (PST) Received: by 10.142.135.9 with SMTP id i9mr1638673wfd.1197227675973; Sun, 09 Dec 2007 11:14:35 -0800 (PST) Received: from macintosh.local ( [89.150.77.105]) by mx.google.com with ESMTPS id 30sm5273920ugf.2007.12.09.11.14.33 (version=SSLv3 cipher=OTHER); Sun, 09 Dec 2007 11:14:34 -0800 (PST) Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <87k5nxw76i.fsf@buckbeak.hogwarts> <87tzmwkdnr.fsf@buckbeak.hogwarts> Content-Transfer-Encoding: 8bit User-Agent: Opera Mail/9.24 (MacPPC) Message-ID: Date: Sun, 9 Dec 2007 20:14:31 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?iso-8859-1?Q?Morten_H=F8gholm?= Subject: Re: Misleading cs names? To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <87tzmwkdnr.fsf@buckbeak.hogwarts> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.599 () BAYES_00,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: 09 Dec 2007 19:19:28.0448 (UTC) FILETIME=[6AFD3C00:01C83A98] Status: R X-Status: X-Keywords: X-UID: 5106 On Wed, 05 Dec 2007 22:57:44 +0100, Andreas Matthias wrote: > Morten Høgholm wrote: > >> On Sun, 02 Dec 2007 14:35:33 +0100, Andreas Matthias wrote: >> >> True, the base form of the function \int_set: does do this x >> expansion. However, these assignment functions are a bit different >> from other types because there is no difference between >> \int_set:Nn and \int_set:Nx and so perhaps it is better to stick >> to the base form definition using Nn rather than Nx as that would >> imply there is a base form too. > > When I first used these functions I added a lot of \exp_args:... and > \exp_after:NN just to realize afterwards that they are not necessary > at all. An x arg-spec would have helped me a lot to get things right > from the beginning. Noted. I see your point. Thanks for the feedback: it is good to know what we can do better in the documentation. My problem with calling it \int_set:Nx is that this implies there is a base form \int_set:Nn but for these functions working with the built-in registers of TeX, it doesn't make much sense to have different specifiers as full scan_(int|dimen|glue) expansion always takes place. So perhaps an alternative could be to use something like \int_set:Nr {expression}% r for register? Opinions? > Should the arg-spec indicate whether a function is expandable or > not? Ideally, no, it shouldn't. It should be clear from the documentation what is expandable and what is not. Something like what Heiko does in zref? Usually the x expansion meant "uses \edef" and so they were all non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have functions doing full expansion like \numexpr and friends and \pdfstrcmp (does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me: the notes from the Oldenburg meeting mentions an \expanded primitive: \expanded Expandable command returning the full expansion of the tokens in . So since this pretty much exists inside \pdfstrcmp as it is now, it could go into pdfTeX 1.50 and we would be free of these problems. Except of course, \expanded is already used a lot in ConTeXt with different semantics. Any opinions from the ConTeXt/pdfTeX people here? Cheers, -- Morten