LATEX-L Archives

Mailing list for the LaTeX3 project

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 3 Jan 2011 16:18:22 +0000
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=windows-1252; format=flowed
From:
Joseph Wright <[log in to unmask]>
Parts/Attachments:
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

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

ATOM RSS1 RSS2