develooper Front page | perl.perl5.porters | Postings from January 2023

Re: Making s:foo:bar: warn "reserved" - contentious idea?

Thread Previous | Thread Next
January 15, 2023 00:43
Re: Making s:foo:bar: warn "reserved" - contentious idea?
Message ID:
On Sun, 15 Jan 2023 at 01:21, Paul "LeoNerd" Evans <>

> Oh totally - prettymuch all of them in fact already *are* implemented
> as special opcodes rather than regular OP_ENTERSUB-based CVs. The point
> of builtin is that the things there *look like* functions. But for
> internal efficiency reasons most of them in fact aren't implemented as
> such. It should be easy to add e.g. builtin::match such that
>   $count = match($str, qr/foo/);
> would compile to the same optree as
>   $count = $str =~ m/foo/;

So I think the main thing is considering the subtleties here. The advantage
of the existing syntax is it gives a (sort of) clear indicator that special
rules are in place for the pattern, and in s/// for the replacement as
well. So at some level we are talking about how would you make that work in
a function like api? Eg, it would be nice if you could do:

replace(/foo-(bar)/, { "baz-$1" }, global=>1);

But then you have to have some way to have special rules for the double
quoted string so that $1 doesnt get interpolated right away. You could use
single quoted strings, and then eval I guess, but there is some ugliness
there.. But it feels doable somehow. Maybe it would be easier to supply a
codeblock on the rhs instead. Make the RHS simply always be a code block or
sub or somthing. /me waves hands.

I do think we are more likely to find something fruitful if we think
outside of the box. As someone who has added new modifiers to the regex I
would welcome an alternative. :-)


perl -Mre=debug -e "/just|another|perl|hacker/"

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