MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <539432A6.7030205@clear.net.nz> <5395A7A3.7040106@residenset.net>
            <5395AA02.8040704@morningstar2.co.uk>
            <CANQYN6x3K5LzThY49V2CYuDj0i6O=M1CJgby9YdS4J6ZDY5UTA@mail.gmail.com> <53BF8686.2060201@morningstar2.co.uk>
            <CANQYN6xf4rqATSeaprCrhK01c0ABU+6drtF7TUEhAu1u0Sqwxg@mail.gmail.com>
            <53C0131F.2030404@morningstar2.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.6.0
Message-ID:  <53C09731.6080004@clear.net.nz>
Date:         Sat, 12 Jul 2014 14:02:25 +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: aparsloe <aparsloe@CLEAR.NET.NZ>
Subject: Re: Juxtaposition in l3fp
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53C0131F.2030404@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 12/07/2014 4:38 a.m., Joseph Wright wrote:
> On 11/07/2014 17:23, Bruno Le Floch wrote:
>> On 7/11/14, Joseph Wright <joseph.wright@morningstar2.co.uk> wrote:
>>> On 11/07/2014 00:20, Bruno Le Floch wrote:
>>>> should change the precedence of juxtaposition-as-multiplication from
>>>> what it currently is (the tightest) to being the same as
>>>> multiplication.  In other words, juxtaposition would behave exactly
>>>> identically to adding an asterisk.
>>> To be clear, continue to allow
>>>
>>>    2x + 1
>>>    2pt + 3cm
>>>
>>> but with
>>>
>>>    2x^2 + 2 = 2*(x^2) + 2
>>>
>>> so for your example 25pc^2 requiring braces (0.25pc)^2?
>>>
>>>> Would that make sense?  Am I missing something crucial (probably... I
>>>> didn't realize when allowing juxtaposition what a mess I was
>>>> creating)?
>>> Seems OK to me (if I've understood correctly).
>> Yes you did.  Cf my other email: how should the change happen?
> As I said there, with a 'breaking' change (which sometimes simply can't
> be avoided) all we can do is warn that there is one. Write the code and
> test properly and I'll worry about the release announcement :-)
> --
> Joseph Wright
I'm swimming away out of my depth here, but I wonder if you need to 
break anything?

My original email on juxtaposition was prompted when I "stubbed my toe" 
on a case where the rigorous application of juxtaposition and its 
precedence level led to a very unintuitive outcome. Once I had 
re-established equilibrium, I thought to myself: OK, that is how l3fp 
does things. Juxtaposition at the highest precedence level is applied 
rigorously (with perhaps one exception). I can adjust my code. The user 
doesn't need to know about what is happening in l3fp. It is after all 
part of l3kernel, part of the engine.

I concluded that email by wondering if it might be possible to graft a 
more intuitive front end onto l3fp -- call it l3calc, say. By way of 
analogy, there is l3keys in l3kernel and l3keys2e in l3packages. Have 
you considered such an option? l3calc would spend most of its time 
putting parentheses around terms and asterisks between them. But nothing 
would be broken, as a change in precedence level in l3fp will entail. 
The "hairy-chested" could continue to use l3fp; less macho types might 
prefer the more intuitive interface of l3calc.

Andrew