>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
Duck & cover Nate- I sugested that weeks ago and the flames are just dying
down in my mailbox..
It'll be an interesting experiement in "community behavior" however. If your
proposal is widely acclaimed or even seriously considered, while mine was
summarily dismissed, then it may be safe to ass
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
32 matches
Mail list logo
