User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13)
            Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
References: <4D20D031.7040803@gmx.de> <4D20DAE9.3070306@morningstar2.co.uk>
            <DE9B7720-FDD0-4CF1-B66F-EB4DC7333D97@yahoo.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID:  <4D21D4CA.70703@morningstar2.co.uk>
Date:         Mon, 3 Jan 2011 13:53:14 +0000
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: \int_eval:n versus \dim_eval:n/skip_eval:n [was Re: l3luatex module]
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <DE9B7720-FDD0-4CF1-B66F-EB4DC7333D97@yahoo.de>
Precedence: list
Status: R

On 02/01/2011 21:03, Philipp Stephani wrote:
> still it would be great if the behavior of the L3 macros were formally defined in TeX terms: I often experience that I cannot use certain L3 macros because it is not documented whether they expand to, say, an<internal integer>  or an<integer denotation>. \dimexpr ... \relax is guaranteed by the e-TeX manual to be an<internal integer>, but what \int_eval:n does is undocumented—in fact, it expands to an<integer denotation>  without trailing space, making things like
>
> \documentclass{minimal}
> \usepackage{expl3}
> \begin{document}
> \newcount\x
> \ExplSyntaxOn
> \x = \int_eval:n { 1 + 1 } 1
> \ExplSyntaxOn
> (\the\x)
> \end{document}
>
> possible. 2e's counters and length were designed to make such effects impossible, but L3 reintroduces them :-(
> \dim_eval:n, on the contrary, expands to an<internal dimen>. I think that is the right choice because it is faster and leads to fewer problems. I think a formal description like the following would be nice:

Looking at this again, it reminds me that I'd already been worried about 
the inconsistency between \int_eval:n and \dim_eval:n/\skip_eval:n. For 
reference, these are defined (effectively) as

\cs_new:Npn \int_eval:n #1 {
   \number \numexpr #1 \relax
}

\cs_new:Npn \dim_eval:n #1 {
   \dimexpr #1 \relax
}

\cs_new:Npn \skip_eval:n #1 {
   \glueexpr #1 \relax
}

My original proposal to deal with this was to include \the in the 
\dim_eval:n and \skip_eval:n definitions. However, looking at it again 
perhaps a better plan would be to alter \int_eval:n to

\cs_new:Npn \int_eval:n #1 {
   \numexpr #1 \relax
}

and say that all three functions need to be treated like the related 
variables: in a context where TeX expects an expression, no 
\<thing>_use:N is required but otherwise it is. (In all cases, 
\<thing>_use:N is let to \the.) So modifying Philipp's example to read

\documentclass{minimal}
\usepackage{expl3}
\begin{document}
\newcount\x
\ExplSyntaxOn
\cs_set:Npn \int_eval:n #1 {
   \numexpr #1 \relax
}
\x = \int_eval:n { 1 + 1 } 1
\ExplSyntaxOn
(\the\x)
\end{document}

then gives the more logical result.

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?
--
Joseph Wright