>I already proposed that. Benchmarks show that reading a file with
>explicit chomp() is easily 20% slower than reading the same file with
>implicit chomp(), through the -l command line switch.
And what, pray tell, do you do about the small matter of wanting
to read some files without implicit rec
On Fri, 1 Sep 2000 08:33:24 -0400 (EDT), Eric Roode wrote:
>For that matter, let's drop chomp(), eh?
I already proposed that. Benchmarks show that reading a file with
explicit chomp() is easily 20% slower than reading the same file with
implicit chomp(), through the -l command line switch.
The
>Bart Lateur wrote:
>>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>>No. People should learn intrinsic mechanisms with which they can
>>>construct infinitely many beautiful and powerful effects. This empowers
>>>them. Making them learn yet-another-function-call merely hamstrings
Bart Lateur wrote:
>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>No. People should learn intrinsic mechanisms with which they can
>>construct infinitely many beautiful and powerful effects. This empowers
>>them. Making them learn yet-another-function-call merely hamstrings
>>th
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>I'm not arguing in favor of the tr/// hack specifically, but
>>gosh, wouldn't it be nice if there were a thwack() builtin that
>>stripped leading and trailing spaces?
>
>No. People should learn intrinsic mechanisms with which they c
>I'm not arguing in favor of the tr/// hack specifically, but
>gosh, wouldn't it be nice if there were a thwack() builtin that
>stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This
TomC wrote:
>In general, getting folks to write
>
>s/^\s+//s;
>s/\s+$//s; # XXX: \z
>
>is a *good* think.
Why?
Removing leading/trailing whitespace is a tremendously frequently-
performed task. Perl gives you -l on the command line to strip
newlines on input and add them on output, sim
>How would you do:
># Writer insists on blank line between paragraphs, first line indented.
># Publisher insists on one paragraph/line, first word ALL CAPS.
Step 1: Fire the lame publisher. I'm serious. It's amazing
what people tolerate. Some things aren't worth the pane.
>{
>local $/ =
>tr///l # Translate only _l_eading characters matching.
>tr///t # Translate only _t_railing characters matching.
>With "Only leading" I mean translate from start/end until you find a
>character not matching. Then you can do nifty things such as:
>tr/\w//dlt # Trim all leading & tra
On Thu, Aug 31, 2000 at 02:52:10PM -0400, Buddha Buck wrote:
> How would you do:
>
> # Writer insists on blank line between paragraphs, first line indented.
> # Publisher insists on one paragraph/line, first word ALL CAPS.
> {
> local $/ = ""; #slurp paragraph at a time.
> while () {
>
At 01:35 PM 8/31/00 -0500, Jonathan Scott Duff wrote:
>On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
> > Why not use the "function" we already got, tr? Something like:
> >
> > tr///l # Translate only _l_eading characters matching.
> > tr///t # Translate only _t_raili
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
> Why not use the "function" we already got, tr? Something like:
>
> tr///l # Translate only _l_eading characters matching.
> tr///t # Translate only _t_railing characters matching.
>
> With "Only leading" I mean transla
On Thu, 31 Aug 2000 19:59:31 +0200, you wrotc:
>tr/\w//dlt # Trim all leading & trailing whitespace from $_
>
Eh, scratch that. Too much caffeine i guess.
tr/\n\r\t //dlt; # Trim some whitespace.
-DZ
--
Tell me your dreams and I will crush them.
On Thu, 31 Aug 2000 09:41:37 -0400 (EDT), you wrotc:
>Nathan Wiger wrote:
>>In a very cool email, Bryan Warnock talked about half a dozen different
>>chop-like functions that are useful but not in core:
>>
>>http://www.mail-archive.com/perl6-language@perl.org/msg01522.html
>>
>>I think chop, cham
Eric Roode writes:
> Useful functions all, no doubt. But I would lobby heavily for a new
> set of names -- ones that can be remembered! Quick -- which trims
> leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
Nathan Wiger wrote:
>In a very cool email, Bryan Warnock talked about half a dozen different
>chop-like functions that are useful but not in core:
>
>http://www.mail-archive.com/perl6-language@perl.org/msg01522.html
>
>I think chop, champ, chip, and friends should be available via the
>
> use St
On Wed, Aug 30, 2000 at 04:34:50PM -0600, Nathan Torkington wrote:
> I wouldn't go that far. It might say something about the difference
> between proposals made as rhetorical devices ("yes, but if that's the
> case then you should be getting rid of X, Y, and Z!"). Really, though,
> I think it's
My first reaction was "NOOO!!" we'll break too much code!
Now, I'm not so sure. Nearly always, chomp() is what is called for;
how often *do* you need to chop off the last character of a string?
And, as someone else pointed out, why not the first character?
"Al" wrote:
>I would actualy lik
Tom Christiansen wrote:
>
> >I'll second that motion. We already have lots of ways of removing the
> >last character of a string if that's what we really need.
>
> But they're slow and hard to read.
I think the word "drop" should be clarified as "dropped from the core
binary".
In a very cool
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
>chomp() is best used for chop()s main raison d'etre, removing $/
>from a string. I say we drop chop().
Works for me. Are you going to RFC it?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source
>I would actualy like to see chop expanded to allow a variable number of
>characters to be removed and a sister function to cut the head off. Yes I
>know you can do this with substr but sometimes when you want the performance
>and need to cut up a string into fields. Lets say the new function is c
>>I'll second that motion. We already have lots of ways of removing the
>>last character of a string if that's what we really need.
>But they're slow and hard to read.
I would actualy like to see chop expanded to allow a variable number of
characters to be removed and a sister function to cut
On Wed, 30 Aug 2000 16:14:35 -0600, Tom Christiansen wrote:
>>I say we drop chop().
>
>So code that says
>
>chop($k,$v)
>
>will need to say
>
>for ($k,$v) { s/.\z//s }
>
>or else something like:
>
>for ($k, $v) { substr($_, length() - 1) = '' }
>
>I'm not sure I find either of those
>I presume that line disciplines will be object-oriented and inherit from
>some base class; therefore a bare chomp will use the line terminator from
>that base class and for the others, you could do something like
>$fh->chomp($line) to do chomping specific to a particular filehandle. Make
>se
At 04:36 PM 8/30/00 -0600, Tom Christiansen wrote:
> >the reason that they're duplicatable with other features, while I want
> >to drop chop because its main purpose has now been replaced with the
> >far superior chomp.
>
>Except that chomp() relies upon the ueberglobal $/ variable,
>irrespective
Tom Christiansen writes:
> So code that says
>
> chop($k,$v)
>
> will need to say
>
> for ($k,$v) { s/.\z//s }
>
> or else something like:
>
> for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things ab
>the reason that they're duplicatable with other features, while I want
>to drop chop because its main purpose has now been replaced with the
>far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the source of the data being chomped.
--tom
Ed Mills writes:
> Duck & cover Nate- I sugested that weeks ago and the flames are just dying
> down in my mailbox..
Whoops, sorry. I didn't realize that had already been submitted.
I just read through the mail archive and didn't see much in the way of
flames there. J.S. Duff wants to keep th
>I'll second that motion. We already have lots of ways of removing the
>last character of a string if that's what we really need.
But they're slow and hard to read.
--tom
>chomp() is best used for chop()s main raison d'etre, removing $/
>from a string. I say we drop chop().
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I'm not sure I find either of
n it may be safe to assume that ideas aren't
considered on merit, but instead on who is the submittor.
-Ed
>From: Nathan Torkington <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Proposal: chop() dropped
>Date: Wed, 30 Aug 2000 14:31:00 -0600 (MDT)
>
>cho
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
> chomp() is best used for chop()s main raison d'etre, removing $/
> from a string. I say we drop chop().
I'll second that motion. We already have lots of ways of removing the
last character of a string if that's what we really
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Nat
33 matches
Mail list logo
