LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Joseph Wright <[log in to unmask]>
Mon, 3 Jan 2011 16:18:22 +0000
text/plain (45 lines)
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


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.

Joseph Wright