develooper Front page | perl.perl5.porters | Postings from October 2021

Re: Pre-RFC: no feature 'filetests';

Thread Previous | Thread Next
Dan Book
October 2, 2021 18:25
Re: Pre-RFC: no feature 'filetests';
Message ID:
On Fri, Oct 1, 2021 at 12:27 PM Dan Book <> wrote:

> On Fri, Oct 1, 2021 at 12:24 PM Paul "LeoNerd" Evans <
>> wrote:
>> A thought which came up on / #perl just now:
>> In very maths-heavy code (e.g. involving 3D coordinates) it's often
>> useful to have things like X/Y/Z or i/j/k as your 3 basis vectors.
>> Expressions like  X+Y  or  X-Z  are fine, but perl will trip up over
>> Y-X because `-X` is a filetest operator; parsing this as a call to
>> Y( -X ) instead of Y() - X(). You have to play whitespace games
>> like `Y - X` or parens like `Y-(X)`.
>> Similar problems happen around -k.
>> Since it is highly unlikely you'd need to perform filesystem tests
>> during such mathsy code, it would be really handy if the filetest
>> `-x`-like operators were controlled by a (default-on) feature flag,
>> that could be turned off in such code:
>>   no feature 'filetests';
>> such that e.g.
>>   sweep(+X, -X);
>>   sweep(+Y, -Y);
>>   sweep(+Z, -Z);
>> now does what I meant.
>> I'm sure there's probably other unrelated fields [pardon the pun] in
>> which it'd be handy to have regular single-letter functions, for
>> which these filetests also get in the way.
>> [[Not directly related to this particular request, but a possible
>>   extension idea is to permit the "parse this numerical literal" part of
>>   the parser to accept some nicer notation, so you can write things like
>>     sweep(3i, -3i);
>>     sweep(2j+3k, -k);  # instead of  -1k
>>     etc...
>>   for which it would similarly be handy to turn off the parser's `-k`
>>   operator]]
> While I agree with the usefulness for avoiding this parser precedence
> quirk, I have two issues with this idea: 1) it's a pretty niche use case to
> warrant a feature flag, 2) this is not a feature we plan to disrecommend in
> any way, unlike the other reverse features we've recently added, or even
> format vars which have less tricky alternatives available under use English.

As mentioned in IRC, I could see this being useful as a standalone pragma,
rather than a feature flag - we'd never add or remove this feature flag
from versioned feature bundles so it doesn't seem useful to put it there,
and it doesn't inherently fit with anything else.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About