Fri, 11 Jul 2014 17:36:33 +0100
On 11/07/2014 17:22, Bruno Le Floch wrote:
>> Actually, I've found this "abuse" quite a handy device, and despite the
>> introduction of the sqrt function to l3fp, for n-th roots, exp(1/n)ln
>> has a certain convenience.
> Well, that won't work once we change the precedence of juxtaposition
> to be the same as normal multiplication. But IIRC, we added (perhaps
> in l3candidates? I'll check) a way for users to define their own fp
> functions. This is still experimental. Looking at it, it seems we
> don't document \fp_function:Nw and \fp_new_function:Npn anywhere.
That code is not in the public distribution :-) (It's in l3trial, which
is on GitHub/SVN but not distrusted further as it's 'very experimental'.)
> No. All programming languages in which function arguments are
> surrounded with parentheses interpret ln(123)**2 as (ln(123))**2, so
> l3fp should as well.
Quite: in the same way, while mathematicians write "sin^2 x", in code
you have to go for "(sin x)^2".
> Now the question is how to implement the change in precedence in the
> least destructive way. I don't think we can have any warning (well...
> that's only mostly true, I have some very experimental code for ugly
> expandable warnings). Should we just do the change brutally?
This one is a 'breaking change', so we have to bite the bullet. We are
well outside of the 'no breaking changes' window we have for the TL
freeze, so what will have to happen here is once the code is checked in
I'll make sure the appropriate CTAN update comes with a warning.