Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
References: <4D20D031.7040803@gmx.de> <4D20DAE9.3070306@morningstar2.co.uk>
            <DE9B7720-FDD0-4CF1-B66F-EB4DC7333D97@yahoo.de>
            <4D21D4CA.70703@morningstar2.co.uk>
Content-Transfer-Encoding: 8bit
Message-ID:  <C99C1A5A-101D-43B3-9338-0273F808ED0E@gmail.com>
Date:         Tue, 4 Jan 2011 01:16:49 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Will Robertson <wspr81@GMAIL.COM>
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:  <4D21D4CA.70703@morningstar2.co.uk>
Precedence: list
Status: R

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.

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.

-- Will