Should Perl have a `chomped` function?
Edit: orginially rchomp, but Aristotle’s suggestion of chomped is perfect!
brian d foy posed an interesting interview question: “What five things do you hate most about language X?” positing that an experienced user of X should know 5 things (s)he hates about it.
In my list is the return value of chomp. Yes I understand why it works as it does
print "chomped" if chomp $input;
but I find that use case happens far less often than the usual
chomp( my $input = <> );
It looks bad, and it is not intuitive, especially to the new user. Just today another one popped up on StackOverflow. This has got to be one of the most common questions on the site.
Wouldn’t it be great to have a chomp function that returns the chomped value or values? In the spirit of the new s///r flag I originally wanted to call it rchomp, Aristotle’s comment of chomped is my new favorite. You would use it like:
my $input = chomped <>;
Since we all love CPAN of course I could make a CPAN module for this, but no one would add a dependency on it just for one convenience function. I don’t expect large adoption of my Tie::Select for this reason, even thought I think it has reasons to be safer than the core’s SelectSaver in some rare circumstances.
So anyway, is chomped something that the community would want? Could it possibly be in CORE:: so that people might actually use it? I even see that a similar concept made an rfc for Perl6. Just daydreaming I guess, but oooh I do hate it.
As I delve into the deeper Perl magic I like to share what I can.
Yes yes yes yes yes yes yes.
I hate that I’m forced to write a procedure every time I want a non-destructive, functional chomping. (Which, coincidentally, is always).
I’d expect the r to mean “right”, as in
rindex. Instead, your module might just overridechomplikeTime::local timedoes.Although it might be nice to have another function that returns the chomped value, it’s not going to solve the problem for people who already don’t read the docs.
brian, you are probably correct on both counts. I envisioned
rchompto mean “return chomp” butrindexis probably the first thing that would come to mind. And nothing makes new Perlers read the docs anyway, so I guess this function would be for us :)When seeing the title I though WTF right-chomp, what would that do.
I think it would be nice to have a version of chomp that behaves as most of us expects but why lengthen the name? Why not something shorter?
AFAIK these are covered in p6 by the trim* methods, no ? The advantage of p6 is that those methods can be cleanly extended/overridden lexically, like
$str.trim( in-place => True, trailing => True );or
my $ret = $str.trim( copy => True, leading => False );IMHO, trim-trailing and trim-leading should be just subcases of the trim method, explicitly encoded in the signature.
Ok so it seems
rchompis out, my next thought ischompr(pronounced “chomper”, i.e. one who chomps). Again theris for return. I like the idea oftrimor even something shorter; remember if its an unusual word, its less likely to clash with existing code.Again, I know this is speculative, and I don’t presume to have any power at all; if I wanted to make a test implementation of this, should it be at the toke/op level with chomp, or should it be implemented higher, i.e. a wrapper for chomp (much easier for a non core-hacker)?
“it is not intuitive, especially to the new user”
Principle of Least Astonishment: Any language that doesn’t occasionally surprise the novice will pay for it by continually surprising the expert.
As it is, the chomp(my $input = <>) is probably the first Perl idiom I leaned, and Perl is like that, and in many cases better for it.
It’s funny how many authors don’t bother to search CPAN first. There already exists String::Trim and Text::Trim and probably others that do exactly this.
That suffers from the same problem. Any “r” that hangs off the name of a string function is going to be thought of as meaning “right” on the first pass.
I think if I were keen on this particular issue I would propose to call the new built-in
chomped. As in,targ, you are correct, I didn’t look at CPAN; the reason is in my article however. I am not likely to add a dependency just for a convenience function. If the implementations in one of those modules is really good, then I would recommend that their code be used for the task.
use File::Slurp my @lines = read_file $file, chomp => 1 ;
and that isn’t just a convenience function. it is also faster than using <>.
if you are reading line by line, chomp isn’t an issue anyhow. rchomp is not needed.
uri
Actually, Perl 6 simply covers this with its own
chomp. In Perl 6, neitherchopnorchompmodify their arguments in-place. This is the case with most (all?) core functions/methods. You could callchomp($line)or$line.chompto return the chomped value, or$line.=chompto chomp in-place. The method-call assignment operator.=is a cool addition to the various assignment operators like+=. The spec used to includep5chopandp5chompbut those were later removed. Also, chomping is much rarer in Perl 6 because I/O handles autochomping by default since that’s what most people want.@Aristotle FTW!
chompedis descriptive and possibly not highly used.@{Uri,Nick}, the truth is this is just daydreaming; I don’t imagine that I can actually get something like this into the (p5) core. Also as I think about it, I wouldn’t even know how, I’m having a hard enough time figuring out where
chompcomes from!(as an aside, Tie::Select could be easily added to the core, possibly renamed SelectSaver::Tie; its only 4 lines and its bulletproof! Wouldn’t you rather rely on a stack rather than destructors?)
daxim points out (on the SO post) that Text::Chomped exists. I haven’t looked at the code, but if its any good, I would support it going core.
Ok not that exact implementation, it should be able to handle an array (rather than an arrayref). Sorry about the noise.