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

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Show All Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Re: \int_eval:n versus \dim_eval:n/skip_eval:n [was Re: l3luatex module] 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 { } } 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 { } } (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