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

trim implementation (Re: PSC #021 2021-05-21)

From:
Nicholas Clark
Date:
May 25, 2021 10:16
Subject:
trim implementation (Re: PSC #021 2021-05-21)
Message ID:
20210525101631.GP9170@etla.org
On Tue, May 25, 2021 at 06:05:31AM +0000, mah.kitteh via perl5-porters wrote:

> In any case, the most concerning aspect of "trim" (or "whim") for me is how it was implemented. Not only the cookie-cutter nature that opens the door for all kinds of silliness (and therefore must be only used judiciously); but the more so the fact that it took took many lines of (necessarily?) grotesque* C/perl API code to implement what can be done in an extremely terse regular expression. In this case, it's clear to me that "trim" has absolutely no business being added internally in the way it currently has been proposed.

> * if you think I am being harsh, it might be my ignorance showing; however I recommend anyone interested take a look at what I mean. No offense to the original author is intended. But the method employed to "extend" perl seems to be ripe for inviting all kinds of crap in the future (again, I could also be super ignorant).

Using "no offence" to attempt to paper over using terms that you know
*might* be offensive isn't OK. Just don't *use* the terms in the context of
other people's legitimate contributions. If nothing else, it's demoralising
and off putting. We don't want to drive away contributors, or potential
future contributors.

Consider this a formal CoC warning.

(I might not written that had I not needed to write the rest of this
message. Be careful what you wish for.)

Assuming that we are talking about:

https://github.com/scottchiefbaker/perl5/tree/trim

1) It's clean.
2) The implementation of pp_trim looks pretty elegant
3) The tests look reasonably thorough

(I guess there should be more for in-place edit, and it would also be good
to test that "in-place" edit isn't triggering accidentally when it should
not - ie that in the default case that the source string actually is
unchanged).


The diff looks like this:

$ git diff --stat 99155265b6644bc3178a61cd413e989b2ecf90d9 scottchiefbaker/trim
 MANIFEST                        |  1 +
 ext/Opcode/Opcode.pm            |  4 +-
 ext/Pod-Functions/t/Functions.t |  6 +--
 feature.h                       | 20 ++++++++--
 keywords.c                      | 13 +++++-
 keywords.h                      | 53 +++++++++++++------------
 lib/B/Deparse-core.t            |  7 ++--
 lib/B/Deparse.pm                |  3 +-
 lib/B/Op_private.pm             |  1 +
 lib/feature.pm                  | 14 ++++++-
 lib/warnings.pm                 | 21 ++++++----
 opcode.h                        |  9 ++++-
 opnames.h                       |  3 +-
 pod/perldiag.pod                |  6 +++
 pod/perlfunc.pod                | 40 ++++++++++++++++++-
 pp.c                            | 88 +++++++++++++++++++++++++++++++++++++++++
 pp_proto.h                      |  1 +
 regen/feature.pl                | 46 ++++++++++++---------
 regen/keywords.pl               |  2 +
 regen/opcodes                   |  1 +
 regen/warnings.pl               |  4 +-
 t/op/coreamp.t                  |  3 ++
 t/op/trim.t                     | 77 ++++++++++++++++++++++++++++++++++++
 t/porting/known_pod_issues.dat  |  1 +
 toke.c                          |  5 +++
 warnings.h                      |  4 +-
 26 files changed, 359 insertions(+), 74 deletions(-)


Yes, that *is* how much C code you need to implement what would be two lines
of Perl. But

1) it's always like that C is more verbose than Perl
2) Have you seen how much C code would get *executed* for the two lines of
   Perl - the regex engine is not small.

(And if you want to read C that *is* ugly, complex, and necessarily so, go
look in regcomp.c and regexec.c)


> Moving forward, I request that in addition to assessing the "need" for "string" functions, there is also some deliberation on *where* these things belong. This should extend not only to "string" functions, but all extensions to "perl core". Ultimately, I'd really like to see this arrive at this more "humane" and "sane" approach to not only providing potential (or experimental) features for "market testing"; but also as a method of finding where they appropriate sit.

We have done this on trim. As Neil observed:

    We've evidence that
    (a) lots of people want to trim things,
    (b) a percentage of them get the regex wrong, and a bigger percentage
    write it inefficiently.
    The inefficiency wouldn't merit adding it, but the other two points do.

PSC feel that it belongs in the core, much like `fc` or `chomp`

So your statement

   "absolutely no business being added internally"

is absolutely wrong.

Your statement:

   But the method employed to "extend" perl seems to be ripe for inviting
   all kinds of crap in the future (again, I could also be super ignorant).


is both wrong and *objectionable*

In that "inviting all kinds of crap" - that is why Neil wrote up
"how to get an idea to a merged PR" where one of the outcomes is
"that could be done as a module";
https://www.nntp.perl.org/group/perl.perl5.porters/2021/02/msg259119.html

so that we find the ideas that really are worth the time and trouble to
spend our limited time on.

And why I've been looking at how to take this a bit further into a
lightweight RFC process so that we can record discussions and decisions (to
learn from them/improve them/streamline them) and more importantly, be clear
how to share out some of the work.

We have many people with ideas, but very few people with the skills to
actually bend the parser and runtime to their will. As the diff above
suggests (and the commit history of the branch demonstrates), a chunk of the
work needed doesn't require those deep internals skills. So PSC are
actively trying to figure out instructions/guides on how to share the work,
so that we can make more progress with the limited resources that we have.


And having to spend time writing message like this is time we can't spend on
actually getting shit done.

> I don't like to shit up p5p about this again, so if I can could be directed to the appropriate email addresses; I'll happily summarize what I envision as a reasonable approach for consideration by the PSC. And it may be burned in effigy for all I care, as long as it helps move us into some sanity regarding the discovery, deliberations, and market testing of useful and interesting "features" (wherever in the perl "stack" they may be implemented).

I'm going to be blunt - yet again, your well intentioned message adds very
little of value, and is distracting the people who are actually trying to
deliver the things that you (quite legitimately) want.

Please note above that you have a formal CoC warning for choice of language
in the context of commenting on the contributions of others.

Nicholas Clark



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