Mailing List Archive

Pre-RFC: no feature 'filetests';
A thought which came up on Libera.chat / #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]]

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On Fri, Oct 1, 2021 at 12:24 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> A thought which came up on Libera.chat / #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.

-Dan
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On Fri, Oct 1, 2021, at 12:27 PM, Dan Book wrote:
> 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.

Agreed. This seems overly niche, especially when there's no "so we should all switch to this other syntax."

--
rjbs
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On Fri, Oct 1, 2021 at 12:27 PM Dan Book <grinnz@gmail.com> wrote:

> On Fri, Oct 1, 2021 at 12:24 PM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
>
>> A thought which came up on Libera.chat / #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.

-Dan
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On 2021-10-02 11:24 a.m., Dan Book wrote:
> 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:
> 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';
>
> 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.

Alternatively I suggest that it may be best for things like this to be
implemented as CPAN modules rather than in core.

And then where this becomes a core discussion is if implementing features like
that, namely lexically turning OFF built-in syntax, can't be done in pure Perl
by a CPAN module or user code, then what are reasaonble more generic changes
that can be made to the Perl core to make such a generic feature possible.

-- Darren Duncan
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On 2021-10-02 1:43 p.m., Darren Duncan wrote:
> On 2021-10-02 11:24 a.m., Dan Book wrote:
>> 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:
>>         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';
>>
>>     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.
>
> Alternatively I suggest that it may be best for things like this to be
> implemented as CPAN modules rather than in core.
>
> And then where this becomes a core discussion is if implementing features like
> that, namely lexically turning OFF built-in syntax, can't be done in pure Perl
> by a CPAN module or user code, then what are reasaonble more generic changes
> that can be made to the Perl core to make such a generic feature possible.

Actually I want to walk back part of what I said, the "in pure Perl" part.

My real point with my second paragraph before was that if a feature like this
file operator syntax removal can't sufficiently easily be implemented as a CPAN
module, either with or without XS, then it could be a core discussion about
removing roadblocks such that the change is sufficiently easy. Although I
suspect but don't know that the required core foundation already exists,
considering the existence of other syntax-modifying CPAN modules.

-- Darren Duncan
Re: Pre-RFC: no feature 'filetests'; [ In reply to ]
On Sat, 2 Oct 2021 14:26:05 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> My real point with my second paragraph before was that if a feature
> like this file operator syntax removal can't sufficiently easily be
> implemented as a CPAN module, either with or without XS, then it
> could be a core discussion about removing roadblocks such that the
> change is sufficiently easy. Although I suspect but don't know that
> the required core foundation already exists, considering the
> existence of other syntax-modifying CPAN modules.

Definitely can't.

The only way I can think to do it involves lots of hackery at the core
of toke.c and/or perly.y, to make those parts of the tokenizer (yes,
really) be conditional on some flag. Maybe expose those bit-constants
to perl-land via some new global; call it ${^QUIRKS} or somesuch.

Then we'd just have

package quirk::filetests;
sub unimport { ${^QUIRKS} |= 0x0001; }
sub import { ${^QUIRKS} &= ~0x0001; }

so now we can

no quirk::filetests;
...

But really, 99% of the work is in core .c file source, not pureperl .pm
files.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/