develooper Front page | perl.perl5.porters | Postings from February 2021

Re: Looking for someone to adopt adding trim() to core

Thread Previous | Thread Next
February 15, 2021 10:44
Re: Looking for someone to adopt adding trim() to core
Message ID:
On Mon, 15 Feb 2021 at 10:30, Christian Walde <> wrote:
> On Mon, 15 Feb 2021 09:19:23 +0100, demerphq <> wrote:
> > On Wed, 25 Nov 2020 at 11:35, Christian Walde <> wrote:
> >> I already explained elsewhere in this thread why Yves' concerns do not apply to trim specifically
> >
> > I didnt see any explanation that I found convincing, sorry.
> Don't just say found them unconvincing but actually refer to them and explain why they're unconvincing, otherwise it would be equally perfectly fine for me to say now that you are unconvincing as well, and then we're in a deadlock because neither is an argument, but a refusal to engage with arguments.

I didnt see anything that looked like a proper rebuttal of my points.
If you feel there is a particular post I should refer to please let me
know its message id.

I will restate my position: we should not add any new keywords to perl
that do not have an "undef" prototype.  That is we should not add any
new keywords to the  language that can be expressed as a normal
function. Note this specially allows adding new control keywords,
which includes operators.

Adding a function that has a defined prototype is problematic because
it gets added via the feature API, which means it is enabled like

  use feature qw(say);

and now we have a say() keyword with the same magic properties of print().

Note that this is basically an import, the only reason say() is not imported as:

use Say qw(say);

is because say() has a prototype that changes the grammar of perl, and
cannot be expressed a perl function. The special magic with the
filehandle is why it cant just be a normal function.

Notice also that "feature" as currently exists is not backwards
compatible. Using it in a perl that doesnt support that feature  will
cause an exception. So anything that needs to be backwards portable
cannot use the feature.

Now, if a function with a *defined* prototype is added to the language
via the feature API it is unnecessarily constrained in the same way.

Compare this with a perfectly normal "baked in function". For instance
lets say we add "trim" as "scalar::trim()" to pertl 5.34. We can also
provide a module on CPAN called "Trim" (or whatever), and then code
can simply use Trim. In modern perls the Trim module is just a shim to
import scalar::trim into your namespace, and in older perls it uses
some perl function or maybe some XS. Now everything is backwards
compatible. People that know they are on a modern perl and want trim
without importing it can do scalar::trim(), you can use it in one
liners, etc.

So perhaps we should extend "feature" to have a well define "back
compat" layer, and then create a CPAN module for with back
compat support built in.

But there ARE cases where we WANT to change the languages grammar. And
that is where "use feature" makes perfect sense. Changing the grammar
is inherently bound to a specific perl, typically there is no way to
back compat such a change. So I would argue we should leave "feature"
for these cases only. Eg, adding try {} catch {}, or a new operator or
whatever. So personally I would not add back compat support to
feature, instead I simply would not use it when it is not absolutely

> > Given a quick survey on this point the simplest solution is for us to
> > agree what built in namespace this should live in and move on.
> What survey?

A visual survey of the comments in this thread.

> > As long as you or anyone else's argument that it should be added to
> > the *language* as a keyword, I will object strenuously, and so will
> > others.
> That's a robust (dare i say combative) statement of intention, but not an argument.
> > [...]
> Please explain simply why trim must be treated differently from say.

say() is like print() it cannot be implemented as a pure perl
function, it requires grammar accomodation. Functions like uc and
ucfirst can be.

$ perl -E'say "$_ prototype = ", prototype() // "undef" for
qw(CORE::print CORE::say CORE::uc CORE::ucfirst);'
CORE::print prototype = undef
CORE::say prototype = undef
CORE::uc prototype = _
CORE::ucfirst prototype = _

This is precisely one of the subtleties that I mentioned in my post.

Also it is kind of worth noting that  uc/ucfirst/quotemeta are more
special than it might seem at first blush, they have special escape
sequence equivalents, which I suspect is why Larry also added them to
the language as a keyword. I doubt we would add a quote escape
sequence like \Q\E to enable trim inside of a dq-string. (Although it
might be nice.) Doing something like *that* might justify a feature.
But then you would lose the back-compat aspect entirely.

Anyway, seriously, we have had long established precedent for adding
things to the language via namespaces like "re", "utf8" and the like.
And we had a summit where we agreed to use namespaces like "scalar"
and "array" and things like that. IMO if you ffigure out the semantics
for trim() [ it looks like even *that* is somewhat controversial] then
propose a patch to add it to universal.xs as scalar::trim and I bet
most folks would go "cool, thanks, applied". The new keyword thing
however has no legs and I expect that it will continue to be rejected
for the reasons I have stated in this mail.


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