Re: RFC 111 (v1) Whitespace and Here Docs
Reply on laptop in wilderness (no network) holydays me void this message by
other messages sent in my absence. Ignore if so.
On Thu, 17 Aug 2000 08:28:50 -0400 (EDT), Philip Newton
<[EMAIL PROTECTED]> wrote:
> On Tue, 15 Aug 2000, Michael Fowler wrote:
>
> > So what's insufficient about:
> >
> > print <<"EOF";
> > Stuff
> > More stuff
> > Even more stuff
> > EOF
>
> Others have already mentioned the "have to count the number of spaces"
> argument. Another one that comes to mind is: assume the above is inside a
> 350-line block. Now I want to put an if($foo==$bar) { ... } around that
> block. To make the inner block look nice, I >% in vi -- shift the whole
> block over by one indent (a tab, two spaces, whatever). Presto, the thing
> stops working. I think the above method (having to add your own spaces, in
> the exact number required at the moment) is too fragile.
Shown case might suggest perl shifts the block between the here start and it's
terminator to the left by the width of the whitespace leading the terminator.
Wow, that would be useful. So,
$s = <
Re: RFC 111 (v1) Whitespace and Here Docs
On Fri 25 Aug, Nathan Wiger wrote: > > I was sorta going under the assumption that <<< would cause leading and > > trailing whitespace to be ignored (not stripped) when looking for the > > end-of-here-doc indicator. Because whitespace is ignored, I was then > > proposing some new syntax for stripping whatever one likes from the > > contents of the here-doc. > > I think there's two ideas here in the RFC, one great, the other > debateable: Ok, lets split in 2 > >1. Ignore leading/trailing whitespace in here string terminators. > All of these should work: > > EOL >EOL > EOL # this is the end of the here doc > > I don't think a special syntax is needed just for this. Make > this the default (so "print < If this makes you nervous, use 'This_is_the_end_of_the_string' > or some other suitably long EOL marker. I will make this RFC 111 issue 2 > >2. That leading whitespace should be stripped off here docs. I > am personally against this, for all the reasons everyone has > mentioned. It's too specific a "special case". And there's > already an extremely easy way to do this (I think TomC posted > it again) in Perl 5. This will be in another RFC. Considering the posts, this might die, but perhaps a more generic filtering of Heredoc input might be more usefull. Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, 24 Aug 2000 21:06:30 -0700, Nathan Wiger wrote: > 1. Ignore leading/trailing whitespace in here string terminators. > All of these should work: > >EOL > EOL >EOL # this is the end of the here doc > > I don't think a special syntax is needed just for this. Make > this the default (so "print < If this makes you nervous, use 'This_is_the_end_of_the_string' > or some other suitably long EOL marker. Exactly. Choosing "EOL" as the end-of-string marker while it exists in the text on a line of it's own ignoring whitespace, is a rather poor choice. There's a reason why you can choose your own end-of-string marker. Well... currently I tend to pick a different EOL marker for every here doc in a script, just to make sure that I don't accidently make one large here doc comprised of two intended here docs and the code between them. There's no syntax error in that. -- Bart.
Re: RFC 111 (v1) Whitespace and Here Docs
> I was sorta going under the assumption that <<< would cause leading and > trailing whitespace to be ignored (not stripped) when looking for the > end-of-here-doc indicator. Because whitespace is ignored, I was then > proposing some new syntax for stripping whatever one likes from the contents > of the here-doc. I think there's two ideas here in the RFC, one great, the other debateable: 1. Ignore leading/trailing whitespace in here string terminators. All of these should work: EOL EOL EOL # this is the end of the here doc I don't think a special syntax is needed just for this. Make this the default (so "print <
Re: RFC 111 (v1) Whitespace and Here Docs
>Unfortunately the quoting on the terminator following << decides the type >of interpolation; we're missing a way of indicating how to recognize the >terminator other than an exact match. If we say thatwe want variable interpolation or not? Which is a pity, 'cos I kinda liked >the idea :-) m'...' vs m"..." (or m/.../ of course) vs m`...` --tom
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: > At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: > >But you don't need that when you can and possibly should just write this: > > > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > > Others may be focussing on the problem of stripping off leading white space > from the here doc contents, but I don't so much care about that because I > think the Ram recipes are fine; I'm more concerned about being able to > indent the terminator and not have to count spaces in the <<. I was sorta going under the assumption that <<< would cause leading and trailing whitespace to be ignored (not stripped) when looking for the end-of-here-doc indicator. Because whitespace is ignored, I was then proposing some new syntax for stripping whatever one likes from the contents of the here-doc. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: > But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal services. > | > | Love and kisses > | > EOF This works for print, but not for other functions where the string is in a single argument, rather than a list. printf( <<<'EOF' =~ s/^\s*\| ?//g, '[EMAIL PROTECTED]', "Michael Fowler", '400' ); | To: %s | | Hello %s, your payment of $%.2f is late. Please pay now. | | Love and Kisses EOF Though, granted, the example is a little contrived. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: >But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal services. > | > | Love and kisses > | > EOF Others may be focussing on the problem of stripping off leading white space from the here doc contents, but I don't so much care about that because I think the Ram recipes are fine; I'm more concerned about being able to indent the terminator and not have to count spaces in the <<. Unfortunately the quoting on the terminator following << decides the type of interpolation; we're missing a way of indicating how to recognize the terminator other than an exact match. If we say that <
Re: RFC 111 (v1) Whitespace and Here Docs
>Basically, it's shorthand for the current syntax:
>$message = <<"EOF" =~ s/^\s*\| ?//g;
>| Attention criminal slacker, we have yet
>| to receive payment for our legal services.
>|
>| Love and kisses
>|
>EOF
>print $message;
>But any inconsistencies or errors in my examples should not detract from the
>general idea.
But you don't need that when you can and possibly should just write this:
print <<"EOF" =~ /^\s*\| ?(.*\n)/g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
{--tom
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote:
> >I thought this problem would've been neatly solved by my proposed:
>
> >print <<<"FOO" =~ s/^ {8}//;
> >Attention criminal slacker, we have yet
> >to receive payment for our legal services.
>
> >Love and kisses
>
> >FOO
>
>
> The result of substituting the leading 8 blanks (which might be tabs!)
> from the very front just once is probably 1, which isn't a very interesting
> thing to print. :-(
Oh, well, there should have been a /g there. And the regex may not work for
everyone (it would work wonderfully for me). If you like:
print <<<"EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
Basically, it's shorthand for the current syntax:
$message = <<"EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
print $message;
But any inconsistencies or errors in my examples should not detract from the
general idea.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 111 (v1) Whitespace and Here Docs
>I thought this problem would've been neatly solved by my proposed:
>print <<<"FOO" =~ s/^ {8}//;
>Attention criminal slacker, we have yet
>to receive payment for our legal services.
>Love and kisses
>FOO
The result of substituting the leading 8 blanks (which might be tabs!)
from the very front just once is probably 1, which isn't a very interesting
thing to print. :-(
--tom
Re: RFC 111 (v1) Whitespace and Here Docs
>Today around 4:30pm, Tom Christiansen hammered out this masterpiece: >: printprint <<" FOO" =~ /^\s+(.*\n)/gm; >Unless, of course, you want `xx oo' to be indented still, and the blank >remain. That requires more thought. > print <<" FOO" =~ m/[\r\f\t ]*(.*\n)/mg; >Will preserve the empty line but not the indentation. >I can't, without more thought, preserve the indentation within this syntax >style. I'd have to break it's scope and have two passes on the data. Oh, I see what was meant now. Perhaps just ignore the heredoc's leading and trailing whitespace, then. The Ram has something on this. First it talks about " FOO", which you can't really do much about and which I now infer was the original thrust, and then the following for helping things stand out better. I'm thinking now in retrospect that dequote() here might have been some Larry code, actually. --tom Another embellishment is to use a special leading string for code that isn't ``real'' yet so that it stands out. For example, here we'll prepend each line with C<@@@>, properly indented. if ($REMEMBER_THE_MAIN) { $perl_main_C = dequote<<'MAIN_INTERPRETER_LOOP'; @@@ int @@@ runops() { @@@ SAVEI32(runlevel); @@@ runlevel++; @@@ while ( op = (*op->op_ppaddr)() ) ; @@@ TAINT_NOT; @@@ return 0; @@@ } MAIN_INTERPRETER_LOOP # add more code here if you wnat } Destroying indentation also tends to get you in trouble with poets. $poem = dequote< function handles all these cases. It expects to be called with a here document as its argument. It looks to see whether each line begins with a common substring, and if so, strips that off. Otherwise, it takes the amount of leading white space found on the first line and removes that much off each subsequent line. sub dequote { local $_ = shift; my ($white, $leader); # common white space and common leading string if (/^\s*(?:([^\w\s]+)(\s*).*\n)(?:\s*\1\2?.*\n)+$/) { ($white, $leader) = ($2, quotemeta($1)); } else { ($white, $leader) = (/^(\s+)/, ''); } s/^\s*?$leader(?:$white)?//gm; return $_; } If that pattern makes your eyes glaze over, you can always break it up and add comments by adding C: if (m{ ^ # start of line \s *# 0 or more whitespace chars (?: # begin first non-remembered grouping ( # begin save buffer $1 [^\w\s] # one byte neither space nor word + # 1 or more of such ) # end save buffer $1 ( \s* )# put 0 or more white in buffer $2 .* \n # match through the end of first line ) # end of first grouping (?:# begin second non-remembered grouping \s *# 0 or more whitespace chars \1 # whatever string is destined for $1 \2 ?# what'll be in $2, but optionally .* \n # match through the end of the line ) +# now repeat that group idea 1 or more $ # until the end of the line }x ) } ($white, $leader) = ($2, quotemeta($1)); } else { ($white, $leader) = (/^(\s+)/, ''); } s{ ^ # start of each line (due to /m) \s * # any amount of leading white space ? # but minimally matched $leader# our quoted, saved per-line leader (?:# begin unremembered grouping $white #the same amount ) ?# optionalize in case EOL after leader }{}xgm; There, wasn't that much easier to read? Well, maybe not; sometimes it doesn't help all to pepper your code with insipid comments that just mirror the code. This may be one of those cases.
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 06:14:10PM -0400, Michael G Schwern wrote:
> Paragraphs.
>
> sub legal {
> print << Attention criminal slacker, we have yet
> to receive payment for our legal services.
>
> Love and kisses
> FOO
> }
>
> Obviously stripping all whitespace in this case is wrong, yet its
> exactly the kind of thing which you'd want to use <<< for. You could
> prescan for the smallest number of leading whitespace and strip that.
> Might be more trouble than its worth.
I thought this problem would've been neatly solved by my proposed:
print <<<"FOO" =~ s/^ {8}//;
Attention criminal slacker, we have yet
to receive payment for our legal services.
Love and kisses
FOO
<<< would be used to indicate leading whitespace on the ending identifier is
ignored (no whitespace is stripped, it's simply ignored in the search for
"FOO"), but nothing else.
However, noone commented on it. Is it too horrible to be contemplated? :)
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 111 (v1) Whitespace and Here Docs
Today around 4:30pm, Tom Christiansen hammered out this masterpiece:
: print <'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: RFC 111 (v1) Whitespace and Here Docs
At 04:30 PM 8/24/00 -0600, Tom Christiansen wrote: > >I'm coming into this a bit late, so forgive me if this is impossible or > >already dismissed, but what about > > > print < > Attention, dropsied weasel, we are > > launching our team of legal beagles > > straight for your scrofulous crotch. > > > xx oo > > FOO > >Rather than > > print < Attention, dropsied weasel, we are > launching our team of legal beagles > straight for your scrofulous crotch. > > xx oo > FOO > >you mean? Right; I was proposing new syntax for recognizing the terminator; it would not have any effect on the intervening text. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 111 (v1) Whitespace and Here Docs
>I'm coming into this a bit late, so forgive me if this is impossible or >already dismissed, but what about > print < Attention, dropsied weasel, we are > launching our team of legal beagles > straight for your scrofulous crotch. > xx oo > FOO Rather than print <
Re: RFC 111 (v1) Whitespace and Here Docs
At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote:
>Okay, devil's advocate.
>
>Paragraphs.
>
> sub legal {
> print << Attention criminal slacker, we have yet
> to receive payment for our legal services.
>
> Love and kisses
> FOO
> }
I'm coming into this a bit late, so forgive me if this is impossible or
already dismissed, but what about
print <
Re: RFC 111 (v1) Whitespace and Here Docs
Okay, devil's advocate.
Paragraphs.
sub legal {
print <
Re: RFC 111 (v1) Whitespace and Here Docs
On Tue, 15 Aug 2000, Michael Fowler wrote:
> So what's insufficient about:
>
> print <<"EOF";
> Stuff
> More stuff
> Even more stuff
> EOF
Others have already mentioned the "have to count the number of spaces"
argument. Another one that comes to mind is: assume the above is inside a
350-line block. Now I want to put an if($foo==$bar) { ... } around that
block. To make the inner block look nice, I >% in vi -- shift the whole
block over by one indent (a tab, two spaces, whatever). Presto, the thing
stops working. I think the above method (having to add your own spaces, in
the exact number required at the moment) is too fragile.
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, 16 Aug 2000, Perl6 RFC Librarian wrote: > This will ignore all leading white space on each line until the end terminator > is found. It effectively does s/^\s*// before processing each following line. I don't agree with this, but > It also ignores whitespace (but not the line termination) after > the terminator. ...I agree with this. > > Personally I find such blocks very usefull for cgi programming, when delivering > large blocks of fixed html. Personally, I find such blocks very useful for lots of things. The majority of my uses require/desire maintaining relative indentations, and not the arbitrary removal of all leading whitespace. Wasn't there a recipe for this? (Although I wouldn't mind seeing it implicit to the language.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, Aug 16, 2000 at 08:22:16PM -0400, Chaim Frenkel wrote: > > "MF" == Michael Fowler <[EMAIL PROTECTED]> writes: > > MF> So what's insufficient about: > > MF> print <<"EOF"; > MF> Stuff > MF> More stuff > MF> Even more stuff > MF> EOF > > > Counting spaces, why make the programer work. Are those tabs or spaces? I would hardly consider counting spaces work, it's fairly typical for the kind of tabbing I use. If I used actual tabs, this would be a total non-issue. > And it doesn't strip the leading whitespace. The RFC doesn't mention that the string will be stripped of leading whitespace, at least not explicitly. It mentions "it effectively does s/^\s*// before processing each following line", but the phrase shortly before that, it "will ignore all leading white space on each line until the end terminator is found" implies that it simply ignores leading whitespace until if finds the EOF. If it strips whitespace I would be more for it. If we can do some magic to dictate what the leading characters to be stripped are I'd say we have a winner here. (Pardon the HTML, but it makes things more relevant.) print < Foo Bar EOF This would still produce nicely-formatted HTML, whereas stripping all whitespace wouldn't. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
> "MF" == Michael Fowler <[EMAIL PROTECTED]> writes: MF> So what's insufficient about: MF> print <<"EOF"; MF> Stuff MF> More stuff MF> Even more stuff MF> EOF Counting spaces, why make the programer work. Are those tabs or spaces? And it doesn't strip the leading whitespace. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote: > With a here doc print < the text of the here doc, is processed verbatum. This results in Here Docs > that either stick out in the code, or result in unwanted leading whitespace. > There are several FAQs that relate to this problem. This proposal tidies > this up. [snip] > This will ignore all leading white space on each line until the end terminator > is found. It effectively does s/^\s*// before processing each following line. > It also ignores whitespace (but not the line termination) after > the terminator. So what's insufficient about: print <<"EOF"; Stuff More stuff Even more stuff EOF Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote: > =head1 ABSTRACT > > With a here doc print < the text of the here doc, is processed verbatum. This results in Here Docs > that either stick out in the code, or result in unwanted leading whitespace. > There are several FAQs that relate to this problem. This proposal tidies > this up. > > =head1 DESCRIPTION > > Suggested syntax: > > print <<
RFC 111 (v1) Whitespace and Here Docs
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Whitespace and Here Docs =head1 VERSION Maintainer: Richard Proctor <[EMAIL PROTECTED]> Date: 16 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 111 =head1 ABSTRACT With a here doc print <
