MIME-Version: 1.0
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>
            <53C09731.6080004@clear.net.nz>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6yz9at5G=ZaiF2jS8t4SVW-1wB6opSPHcsFprJWx_9LMA@mail.gmail.com>
Date:         Fri, 11 Jul 2014 23:13:02 -0400
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Juxtaposition in l3fp
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53C09731.6080004@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 7/11/14, aparsloe <aparsloe@clear.net.nz> 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 <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.

Can you expand on that one exception?  I don't see what it is.

> 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

I disagree.  Implementing a parser with all the properties we need (in
particular, expandability) is difficult and requires a lot of code,
which would have to be essentially duplicated from l3fp into a
hypothetical l3calc for a very minimal advantage if it is just
correcting the precedence of juxtaposition.  Is there any other change
that such an l3calc should make (basically, what else should we change
in l3fp)?

Making a breaking change to l3fp is not great, but hopefully this
particular aspect has not been used too much (I'd be more wary of
forbidding juxtaposition altogether), and won't break any document.

Regards,
Bruno