On 12/07/2014 3:13 p.m., Bruno Le Floch wrote:
> On 7/11/14, aparsloe <[log in to unmask]> wrote:
>> 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 <[log in to unmask]> 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.
> Can you expand on that one exception?  I don't see what it is.
I found myself on occasion wanting to substitute a number in expressions 
where  pi is followed by other terms. For instance the fine structure 
constant is 2pi e^2/hc (where e is the electronic charge in this case) 
but direct substitution of values for e etc. simply provokes an 
"Undefined control sequence" message. Since numbers are not (as far as I 
understand) elements of control sequences, this felt like an unnecessary 
limitation. (But I'm not familiar with the underlying constraints. Hence 
the "perhaps".)

As I've tried to indicate, I've come to realise that what matters is 
clarity in what the rules are and the rigour of their application. My 
concern was with people who might, at present, use a (clunky?) package 
like calc, or fp, coming across l3fp, being seduced (like me) and coming 
a cropper (as I did). The proposed change will certainly reduce that 
possibility.

Andrew