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] Frank Mittelbach <[log in to unmask]> Wed, 5 Jan 2011 23:54:58 +0100 text/plain (78 lines) somehow it looks as if I haven't got Philipp's original mail. was that not send to latex-l? anway ... Joseph Wright writes:  > 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. Joseph gave a bunch of examples, but in general you also have the point of bootstrapping to consider. Clearly \int_eval:n wouldn't be a command for arbitrary use, but you need as part of setting up the inner kernel commands and you need it in modules that provide new type or provide conversion from some datastructure to some other. What can be argued is: is it so low-level that nobody outside the kernel should use it? I don't think so, but it is certainly true that in package code you would normally not need it.  > > [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. It would be inappropriate for the reason you give. But also for another one. I sure have changed my mind several times about how to think about :nox argument specs. but these days I'm fairly convinced that one should without execption think of them (and describe them) as manipulating the arguments prior to passing them to the base function. So \int_eval:x would first do the "edef" expansion on the argument and then pass it to \int_eval:n which would do what? no I think it is perfectly okay to have commands that do something with their "n" arguments in fact all of them do something with the argument content only in some cases it involves expansion which you could also do "prior" to calling the command using the ":nox" approach    > > [3] Let's define all macros as non-outer LaTeX 2e already attempted to get rid of \outer and expl3 doesn't have the concept at all. I'm not sure we actually bothered to undefine it, but we should probably do so.  > 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? don't like it I fear. \int_use:n doesn't exist what exists is \int_use:N which is using a integer register at least that is what it is supposed to do conceptually I think that the int side is fine \int_new:N \foo \int_set:Nn \foo {5+6} \int_use:N \foo yields 11 (no space after it) and so does \int_eval:n{5+6} I think what is wrong is what you initially pointed out that \dim_eval:n behaves differently ... but I think that would be best resolved by adding \tex_the:D in the right place. At least that my current thinking on the topic. frank