## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 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 >>]

On 03/01/2011 15:03, Philipp Stephani wrote:
> There should be no places where \int_eval:n is actually needed if you stick to pure L3

Well, that's not really true: there are at least two cases where you do.
First case, error messages:

\msg_error:nnx { some-module } { some-message }
{ \int_eval:n { <user-input> } }

which comes up from time to time. Secondl there are places where you
want to store an int/dim/skip in a token list, but want to validate at
the point of input and not some time later:

\tl_set:Nx \l_some_tl { \int_eval:n { <user-input> } }

(This comes up in some galley code I'm working on, so I do have real
cases in mind here.)

> [1] maybe the function should even be called \int_eval:x?

I'd noticed a while ago that all of the int/dim/skip functions look a
bit like 'x' expansion. There are a few odd 'x' type functions, but in
general they should be \edef-like in expansion. This means that
\protected macros should not expand inside 'x' expansion. However, they
are expanded by \numexpr, etc. So 'x' seems inappropriate here to me.

> [2] token lists don't have to be mentioned here since they have disappeared after expansion. If you mention them, you would also have to mention macros. Better to say that the argument is expanded exhaustively—or even more than that, since protected macros are expanded as well. This again reminds me that you should document when protected macros are expanded.

I can see your point here. (I got caught out with \romannumeral
recently, as I'd missed that it also expands \protected macros.) That
applies to all of int/dim/skip: should be a general note, I think.

> [3] Let's define all macros as non-outer

Indeed.

Stepping back a bit, I see that \int_use:n (etc.) might make more sense
for expandable definitions (yielding numbers which are not 'safe', i.e.
as though they were simply typed into the input stream) and \int_eval:n
(etc.) for assignments, etc.

Thoughts?
--
Joseph Wright