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

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

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
January 15, 2023 00:22
Subject:
Re: Making s:foo:bar: warn "reserved" - contentious idea?
Message ID:
20230115002145.0ada25d0@shy.leonerd.org.uk
On Sat, 14 Jan 2023 21:48:46 +0100
demerphq <demerphq@gmail.com> wrote:

> Having given this some thought, I have to say I am not thrilled with
> it.  I am not outright opposed but the math on it doesn't seem to add
> up to me. It seems like we are trying to carve ourselves out of a
> corner we painted ourselves into without simply reconsidering our
> whole approach to the problem.  So for instance, if we can change the
> syntax to forbid ":" and etc, and then extend s/// so that it takes
> an attribute style api then we have the chops to simply create a
> builtin::replace() function or a replace() feature/keyword[1] which
> behaves like a proper function and provides us a nice normal API to
> add stuff like you want.
> 
> I have to admit I kind of like the idea of having a way to match the
> Nth item or other neat features like that.  It just feels a bit
> desperate to try to cram extra parameters into the current API via
> this colon syntax. There is nothing to say we cant have a functional
> equivalent of m// and s///. That IMO would both provide you a way to
> do fancy things like you want, and also would go a long way to
> address the "line noise" reputation of perl.

Hmmm... That said I think that is a fair point. Much like the fact that
<$fh> is *weird* syntax and readline($fh) makes it much much nicer,
perhaps the way to attack this isn't to carve up more special weirdness
out of s/// but instead provide syntax that (at least on a superficial
syntax level) looks like a regular function call would be better.

<snip>
> So really, I would rethink this. I think it will take a lot of work
> and elapsed time, along the way it will annoy a bunch of people, and
> likely never really be a satisfying way of extending the api. Instead
> why not take an approach that gives you lots of room to extend the
> API, and will not annoy people and might even make them happy, and
> which is doable more or less today if you wanted to.

Yes; more fair points there.

> [1] not sure if its feasible to make a builtin actually create normal
> opcodes, but if it is then we could use the builtin namespace.

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/;

-- 
Paul "LeoNerd" Evans

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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About