Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id s6C4njMW010325 for ; Sat, 12 Jul 2014 06:49:46 +0200 Received: from relay.uni-heidelberg.de ([129.206.100.212]) by mx-ha.gmx.net (mxgmx008) with ESMTPS (Nemesis) id 0MS1pC-1WzncU0Hk2-00TGMU for ; Sat, 12 Jul 2014 06:49:40 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s6C4lF79021903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jul 2014 06:47:15 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s6BM15SG022487; Sat, 12 Jul 2014 06:47:15 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 11125517 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 12 Jul 2014 06:47:15 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id s6C4lEJR014055 for ; Sat, 12 Jul 2014 06:47:14 +0200 Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id s6C4l1UK021839 for ; Sat, 12 Jul 2014 06:47:05 +0200 Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0N8L00A511ABRW20@smtp3.clear.net.nz> for LATEX-L@listserv.uni-heidelberg.de; Sat, 12 Jul 2014 16:47:00 +1200 (NZST) Received: from 121-74-37-224.telstraclear.net (HELO [127.0.0.1]) ([121.74.37.224]) by smtpin1.clear.net.nz with ESMTP; Sat, 12 Jul 2014 16:46:59 +1200 MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Antivirus: avast! (VPS 140711-1, 12/07/2014), Outbound message X-Antivirus-Status: Clean References: <539432A6.7030205@clear.net.nz> <5395A7A3.7040106@residenset.net> <5395AA02.8040704@morningstar2.co.uk> <53BF8686.2060201@morningstar2.co.uk> <53C0131F.2030404@morningstar2.co.uk> <53C09731.6080004@clear.net.nz> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 Message-ID: <53C0BDC3.9010007@clear.net.nz> Date: Sat, 12 Jul 2014 16:46:59 +1200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: aparsloe Subject: Re: Juxtaposition in l3fp To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:Foy/ek8LV/s=:RxHKyigIKsdS5GIHcENdsg8zZF 2Nv7tKAVL3/eWdyeBcNf7ofY9MqiO/fdeyjNXCRSApPSpQNkMmgT3uXzkbHnTXpU94Xhm6qrK eDTLvSfSsJ71Lch8r0O7VgRLW130IMG5IjoCVqIEsRKu6e3N9Panb1qdC9CwK3AineuDZkAnc 6a+Oye0aPRmprqPnjnhnreNxvDDfN2hz4p+fY+HwXYNBH5ohUOUohqvvh7YSqP7bpLdm2IIIN 5YBXBt9HXQCaXKWCO1f3MvlSD4pOxa2Dhd33+Lrg/UAVi3obsnCZgjNjvVAjvLtRD623I9BnM Ddj+jzIjA4jed4tptoUVhzpXpjsvSWe0TBzKCrRXAocMKAMtugez2QssnexPk/6JLSWo9tyNP 3QgeuYvsFdak2bzOFB2/8DQ3TQj/Le70Tx4guk7CwALwP6kybvEBFzpqr+/xHGckIowyX201r xnczGsWAtvLk+hLDZzqVzsq9byvUC/giZLmupydmC0l4oq/jx8tPz0OgdVU1b27en5/isC1bu oaVuTBDsqtD2zbaTV4Xfmil2xz/ZR0nrh4h42Q0krMZJNNKt/4n673u/6w7zrnvwX7kBTtv2K ETAAQpXI0O4jWoJm8RBxetO2l5/c3mYHIzxj+6m2eGLPNFYoDoESFJgl9xiCAwSf4B4r0OYRM q62bTtfqW2GjgRCw4a5Ve3dNz9vj5cLLV81wO3iHiE+5+4GD7qmIewQUTImzPhP/Pjmt/o1eu zDokSsPkJ2qc5deZZCcYhvY3NPTt1iFpiPkDm+CSCP7nSM61VL0endp2z05pYcQll9pVygWt8 BLQJvfr5ZBISTvmX+K42wCQgjdM34VJUuE96qpo7OyKFWVCsjG5/5SjqFRxsVmbXWqI8sLK51 ykhOvPRn3Yl+WWSEhLLrFxxjP42bm6j1FrJUQRuv1OA03aoIuo3LQ1QGv4obqqMckQr/h6BRa iHtk+yzYmgI5Onw6zdOEqpcSoYkq0pPiBR2FvC1w/7ky1aN81qzRLmx/ruiDsLliXwXOlyD4B ljXT2ORIhC+l38ISVztEhXP5hgDMMjTor8m8lIbvGZ/10OP2of/ftuPbERWEzQOzJ3BEjFyI1 0ozkIdssRfsc+J7gtWOGtKNpErr9HxwkyPMvJxpT4+cS25/lCUk46LsA/TSvzZIrNAuOvRjzz YA8A33688IscdtNtdbi9WYjQqecKmmx++jMLRCZYHcaprLvbrKY98gZVX6mNGHtBtT6Hb92uH FHzIBHdClQQunbLs9WSgZQrg85DXc03lvTSz+vFTTD9arZP8W/592W2Qrw5NmbbkRirZ9BAYS nLFzaEvRSvmLrlY1rRl+rKgfkRZZhkbSRtUdXwhxfX9bSplUKofYd2ocH5kOaW8ulL3WKeWaS UvjcWd3gUmV0n6cYQaGlPQ5iplovLZBsXBQIcCv0mdSxSJSSvnHPs6jEYa2YFFjAeBPTR5Grl lIN7tCFGNdlZfMzYShFod3iiSKyCIGuHZ6ERuSlcqTJgAhUwyqbx79U/nHYMGLk/fz9xptgg= = X-UI-Loop:V01:lFc/VnMRqGA=:M6wBJQDUd7LOJ1zxu4ysSkZygG3zFxbRJWMjK+QtXHU= Status: R X-Status: X-Keywords: X-UID: 7549 On 12/07/2014 3:13 p.m., Bruno Le Floch wrote: > On 7/11/14, aparsloe 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 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