MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.2.0
Message-ID:  <56020530.4070302@clear.net.nz>
Date:         Wed, 23 Sep 2015 13:49:36 +1200
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: Andrew Parsloe <aparsloe@CLEAR.NET.NZ>
Subject: An incomplete int-erface?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

\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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus