Front page | perl.perl5.porters |
Postings from January 2023
On Sun, 15 Jan 2023 at 01:21, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
> 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. :-)
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next