On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
> I'm all for solving problems, and this message attempts to specify 3
> problems, but it needs more specification. You describe three
> problems, but it is not clear what the problems are
Since we've been charging back and forth over this ground like a troop
of doughboys over No Man's Land for the past month, I figured everyone
knew the problem and proposed solutions. Your review accuractely lays
everything out.
> { { { { {
> if( $is_fitting && $is_just ) {
> die dequote_like('!', <<POEM);
> ! The old lie
> ! Dulce et decorum est
> ! Pro patria mori.
> POEM
> } # this } had been omitted
> } } } } }
Things like this have come up, and to my eyes and fingers its
unacceptable. Some people like the explicit demarcation of the left
boundry, I find it ugly and don't like the extra typing. It doesn't
win me much over:
die
' The old lie'.
' Dulce et decorum est'.
' Pro patria mori.';
I'd prefer if here-docs just DWIM.
So we may want to add Yet Another problem. I forget what number you
got up to, but its basically "You shouldn't have to add anything but
whitespace to the here-doc for indenting".
An additional problem with dequote() style solutions is they are not
as efficient. <<DOC =~ s/// and the terminator indentation can both
be applied at compile time and deparse the whole mess into a simple
string (as the prototype does), while the dequote() routine must be
run over and over again at run-time. This can get nasty in hot loops.
#!/usr/bin/perl -w
use strict;
use Benchmark;
sub dequote_like {
local $_ = shift;
my ($leader); # common white space and common leading string
if (/^\s*(?:([^\w\s]+).*\n)(?:\s*\1.*\n)+$/) {
$leader = quotemeta($1);
} else {
$leader = '';
}
s/^\s*$leader//gm;
return $_;
}
my $foo;
timethese(shift || -3,
{
dequote => sub {
$foo = dequote_like('!', <<POEM);
! The old lie
! Dulce et decorum est
! Pro patria mori.
POEM
},
terminator => sub {
use RFC::Prototype::111;
$foo = <<"POEM";
The old lie
Dulce et decorum est
Pro patria mori.
POEM
},
});
Benchmark: running dequote, terminator, each for at least 3 CPU seconds...
dequote: 2 wallclock secs ( 3.00 usr + 0.01 sys = 3.01 CPU) @ 39857.81/s
(n=119972)
terminator: 3 wallclock secs ( 3.00 usr + 0.02 sys = 3.02 CPU) @ 268209.93/s
(n=809994)
dequote() comes out nearly seven times slower than the terminator
approach (which is basically dequote() vs a plain string).
So that's another problem to add to the list. "here-docs should be no
slower than the equivalent string, indented or otherwise"
> The syntax for <<POEM =~ s/regex/subst/;
>
> generally returns 1, and introducing a special case to make it
> return the string if the left hand side is a here-doc seems to be a
> pointless inconsistency.
I think its considered closer to the current trick of doing:
print ($var = <<POEM) =~ s/regex/subst/; # or something like that
Another suggestion was <<POEM =~ m/re(ge)x/. The match would be run
over each line and $1 used to generate the here-doc.
Honestly, I'm not really the one who should be evangelizing this
technique.
> but these subs [dequote] work in perl 5 today, so don't really need
> to be part of the RFC
They most definately do. If we're going to propose them as a solution
to the indented here-doc problem, it would be best to distribute a
collection of commonly used ones as a module with perl.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
slick and shiny crust
over my hairy anus
constipation sucks
-- Ken Flagg
