MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4D20D031.7040803@gmx.de> <4D20DAE9.3070306@morningstar2.co.uk>
            <DE9B7720-FDD0-4CF1-B66F-EB4DC7333D97@yahoo.de>
            <4D21D4CA.70703@morningstar2.co.uk>
            <2F1A4A24-7C35-4C2A-8E80-115DCD9510DF@YAHOO.DE>
            <4D21F6CE.10504@morningstar2.co.uk>
Message-ID:  <19748.63170.237158.614517@morse.mittelbach-online.de>
Date:         Wed, 5 Jan 2011 23:54:58 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: \int_eval:n versus \dim_eval:n/skip_eval:n [was Re: l3luatex module]
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4D21F6CE.10504@morningstar2.co.uk>
Precedence: list
Status: R

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