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 p05MHGUi014027 for ; Wed, 5 Jan 2011 23:17:17 +0100 Received: (qmail 30480 invoked by alias); 5 Jan 2011 22:17:11 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 05 Jan 2011 22:17:10 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx064) with SMTP; 05 Jan 2011 23:17:10 +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 p05MFULU004356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jan 2011 23:15:30 +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 p05J3uc6002376; Wed, 5 Jan 2011 23:15:24 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 816084 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 5 Jan 2011 23:15:24 +0100 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 p05MFOlL030024 for ; Wed, 5 Jan 2011 23:15:24 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p05MFKlH004152 for ; Wed, 5 Jan 2011 23:15:23 +0100 Received: from morse.mittelbach-online.de (p3EE3E037.dip.t-dialin.net [62.227.224.55]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MQA1H-1Pfqh22FrH-005Dsw; Wed, 05 Jan 2011 23:15:20 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id ABCE272963; Wed, 5 Jan 2011 23:15:16 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4D20D031.7040803@gmx.de> <4D20DAE9.3070306@morningstar2.co.uk> <4D21D4CA.70703@morningstar2.co.uk> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:bLwtEwrzvQRk8pxb9/bjcjqhCk8aHQ7V2uSBu81v2A8 Rq2zSqM+KpRrdTdTlu9Y2sz3JT2JsGNdxy8076I0ulcRD03LAW Xy/Klw5tIqBfztSIlo/bp94jj0pLjPsOFogiKF85zxAKwEqRTW ApNsbuPbKWMMClj/6KtJwBxkBjCUCp4a5DLbsbNWLOwodu3Qaw GQyu0Q/epzuLbxstzyfHg== X-Spam-Whitelist-Provider: Message-ID: <19748.60788.604843.540011@morse.mittelbach-online.de> Date: Wed, 5 Jan 2011 23:15:16 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: \int_eval:n versus \dim_eval:n/skip_eval:n [was Re: l3luatex module] To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p4U4jfdfC5HDevlx1X2sAZg1MkugZcpwIdDb8z5l6KEaP+LdZ7QLw+5CKzyp k5HTLZ1v8wPRqFdQdQapWq9qz59Rr52fCiljKsM85i3sbXAJVBjnzZkoSL42zBmmwDa5vja6zT3o 7boow==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: 6525 Will Robertson writes: > On 04/01/2011, at 12:23 AM, Joseph Wright wrote: > > > The resulting documentation might read > > > > % Evaluates the \meta{integer expression}, expanding any > > % integer and token list variables within the \meta{expression} > > % to their content (without requiring \cs{int_use:N}/\cs{tl_use:N}) > > % and applying the standard mathematical rules. This process requires > > % two expansions. The result of the calculation is an > > % \meta{internal integer} which should be treated in the same way > > % as a \texttt{int} variable, \emph{i.e.}~it must be prefixed > > % by \cs{int_use:N} unless used in a context which requires an > > % \meta{integer expression}. > > > > (with similar statements for \dim_eval:n and \skip_eval:n). Is this > > sufficiently accurate and clear? Does the entire proposal make sense? > > I *think* this is sensible, but I'd be surprised if this wouldn't require > some extra changes in some of the internal expl3 functions. The fact that > \int_eval:n is expandable is probably exploited in a few places (at least > in \int_compare:n, anyway). But I'm sure this isn't an insurmountable > problem. you can bet that making this non-expandable will break the kernel in many places. I guess this is essential to a lot of code that Morten has written. Perhaps you could take \number out and put it in front in all such places, but whether that is better I wonder. Morten are you listening right now? > There's not really a sensible alternative for \glueexpr is there? It would > be fine to have \number before the \dimexpr version as well, but without > consistency between all of them we should definitely (er I think) choose > the change that you're suggesting. are we sure the \the isn't the right thing to apply before \glueexpr, ie Joesph's original thought? I rather think that would be better than taking out exansion from \int_eval:n frank