Front page | perl.perl5.porters |
Postings from January 2023
Re: Making s:foo:bar: warn "reserved" - contentious idea?
Thread Previous
|
Thread Next
From:
demerphq
Date:
January 14, 2023 20:49
Subject:
Re: Making s:foo:bar: warn "reserved" - contentious idea?
Message ID:
CANgJU+XnxR4caDM1kYh_uiV+hKRvRvTqHahfmFh=OKFpNmeyXg@mail.gmail.com
On Sat, 14 Jan 2023 at 15:40, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
> I have a longterm thought that one day it'd be nice if we could have
> more, and more descriptive, string quoting and regexp flags - especially
> on substitutions. For example, I'd love to be able to replace only the
> third "foo" with "bar" by doing something, maybe using syntax like this:
>
> $str =~ s:nth(2)/foo/bar/;
>
> I haven't thought it through any further than "I would like the colon".
>
> That's a problem because currently colon just behaves like any other
> delimiting character.
>
> $str =~ s:nth:replacement:;
>
> Oops.
>
> I would therefore like to ask how people would feel about perl printing
> a reserved-style warning whenever a quoted string or regexp uses a
> colon for its delimiter. That is to say, any of the following forms
>
> q:string:
> qq:interpolated string:
> qw:quoted word list:
> qx:executed string:
>
> qr:regexp literal:
> m:regexp match:
> s:pattern:replacement:
> tr:trans:literation: or y:trans:literation:
>
> would all print a warning something to the effect of
>
> Use of ':' as a quotelike delimiter is reserved for possible future
> use at FILE line LINE.
>
> For now I'm not suggesting doing anything to change the actual
> behaviour. Programs would run as they do now aside from that
> (compiletime) warning. Additionally I don't have any specific concrete
> suggestion for a plan of exactly what syntax these would use.
>
> I just feel that the earlier we get that reservation in, the sooner in
> the future we can start to think about actually using it.
>
>
> Thoughts?
>
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.
I also think that ultimately a lot of folks will have chosen ":" as their
quote symbol for various reasons, and while I alm loathe to use the trope
"doesn't feel perlish", I will go so far as to say that making the colon
special this way doesn't feel like something Larry would do (he might
regret not excluding it from the start, but change it in mid flow?). I
mean, '#' isn't even special, nor for ages was ' ' itself. :-) Also if we
are to wait for the deprecation cycle, and the complaining cycle to
complete it will be many releases before you can have your new shiny
features. If you choose a functional API you could have it almost
immediately.
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.
cheers,
Yves
[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.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next