LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 3 Jan 2011 13:53:14 +0000
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=windows-1252; format=flowed
Joseph Wright <[log in to unmask]>
text/plain (77 lines)
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

\cs_set:Npn \int_eval:n #1 {
   \numexpr #1 \relax
\x = \int_eval:n { 1 + 1 } 1

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