References: <56020530.4070302@clear.net.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Message-ID:  <56025C88.6050307@morningstar2.co.uk>
Date:         Wed, 23 Sep 2015 09:02:16 +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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: An incomplete int-erface?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <56020530.4070302@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 23/09/2015 02:49, Andrew Parsloe wrote:
> \int_eval:n { - (1+2) }
> 
> gives a "Missing number, treated as zero" message. So does \int_eval:n {
> + (1+2) }. But
> 
> \int_eval:n { 0 - (1+2) }
> 
> evaluates correctly. If + ( or - ( are the first members of an integer
> argument, an error results; if they are not the first members, they are
> accepted by \int_eval:n etc. I don't know that this is a bug as such but
> it certainly feels to me like an untidiness in the l3int interface. It
> means that the order in which component parts of an expression are
> presented to \int_eval:n matters, even though in an arithmetical sense,
> they evaluate to the same number.
> 
> I query too whether an expression like
> 
> \int_eval:n { 3(1+2) }
> 
> should "evaluate" to 3(1+2), rather than 9, without showing an error.
> 
> (Alternatively, I find myself wondering what would be entailed to
> harmonize the integer interface with the fp one (which has no problem
> with these expressions)? Then one could choose whether to evaluate an
> expression involving integral numerals  in l3fp or l3int without having
> to change the expression, as one does at present. For instance, if the
> expression involves an exponent, use l3fp; if not use l3int. This choice
> becomes more complicated when the expression itself needs to be changed.)
> 
> Andrew

The different 'behind the scenes' here is that \int_eval:n is just the
engine \numexpr primitive in a macro wrapper, but \fp_eval:n is
implemented entirely in macros (as there is no floating-point
primitive). Thus while we can alter the parser for fp work, we can't for
int work, or rather not without significant changes. In particular,
there would be a performance implication in parsing int input and doing
the calculations 'by hand'. I suspect int parsing would be easier than
for fp expressions, but even so this looks like a significant effort.

As Will has commented, we might manage at low cost to avoid the bracket
issue, but allowing \int_eval:n { 3(1+2) } would be rather more tricky.
Indeed, I'd probably say we shouldn't: here I think requiring an
explicit "*" is the right approach. Bruno is best-placed to comment on
the fp implementation here.

The reason I'm wary of making any changes, quite apart from effort both
in terms of the team and in terms of TeX when using expressions, is that
life gets more complex when you look at dim/skip/muskip cases. There,
the underlying primitives have particular requirements, thus

    \dim_eval:n { 4pt * 3 }

is valid but

   \dim_eval:n { 3 * 4pt }

is not. I really don't think we want to implement all of the necessary
parsing for this by hand, so saying that we follow the underlying
primitive requirements is a position I think we are best with in general.

BTW, as far as I know there is nothing that would be valid for an int
expr. that would fail for l3fp.

Joseph