## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```On 12/07/2014 4:38 a.m., Joseph Wright wrote:
> On 11/07/2014 17:23, Bruno Le Floch 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
```