Tom Christiansen wrote:
I am certainly in strong favor of a simple and visually distinctive
solution, and find that the leading bit helps a lot. But I would probably
have written that as:
die POEM =~ /[^!]*/g;
!The old lie
! Dulce et decorum est
! Pro patria
But Tom, that preserves all the white space both before and after the '!'!
Michael's goal is to eliminate the leading white space, although he didnSNIP
'!' bit. So I'm not sure how you'd have written that if you'd have doneSNIP
specification.
Yeah, ok. I still think
# Your stuff that
This is the problem that currently here-doc content must be relative to SNIP
indented code.
2 Preserving sub-indentation.
This is not _currently_ a problem. Perl _currently_ preserves indentatiSNIP
the way, that this problem is a problem. If problem 1 were solved by inSNIP
the HERE
Dave Storrs [EMAIL PROTECTED] writes:
[...]
print FIRST_HERE_DOC; print SECOND_HERE_DOC;
This is on the left margin.
This is indented one char.
FIRST_HERE_DOC
This is indented one char.
This is on the left margin.
SECOND_HERE_DOC
RFC 111
On Thu, Sep 14, 2000 at 03:36:10PM -0700, Nathan Wiger wrote:
See, this is just too inflexible. The main complaint that I've heard has
been "You can't have leading or trailing whitespace around your
terminator". This is a very common error made by everyone, and *this* is
where Perl should
Michael Schwern wrote:
See, I never understood this. If you're indenting the terminator, it
implies you're also indenting the here-doc text. I mean, this doesn't
make any sense:
{ { { {
print TAG;
I don't know what their
gripe is. A critic is
simply someone paid to
render opinions
Michael G Schwern wrote:
See, I never understood this. If you're indenting the terminator, it
implies you're also indenting the here-doc text. I mean, this doesn't
make any sense:
{ { { {
print TAG;
I don't know what their
gripe is. A critic is
simply someone paid to
) removes whitespace equivalent to the smallest whitespace (d)
or are these the options that will satisfy everybody [no but its worth a
try]
1) Does just what it does now
2) implements (d) or (e)
I'd say:
1) does what it does now mod RFC 111 (ie. you can put whitespace
I'm happy with this solution, it seems to address everyone's needs.
-Nate
Michael G Schwern wrote:
I'd say:
1) does what it does now mod RFC 111 (ie. you can put whitespace in the
terminator, but it doesn't effect anything)
2) does (e).
On Thu, 14 Sep 2000 03:11:54 -0400, Michael G Schwern wrote:
The current stumper, which involves problems 1, 2 and 3 is this:
if( $is_fitting $is_just ) {
die POEM;
The old lie
Dulce et decorum est
Pro patria mori.
POEM
}
I propose
Richard Proctor wrote:
Maybe I'm being too simplistic, I don't use tabs anymore.
Yes you are, the problem comes with mixing editors - some use tabs for
indented material some dont, some reduce files using tabs etc etc. [I move
between too many editors]. Perl should DWIM. I think that
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is
On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
The rest is handled adequately and consistently today, and Tom's
dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "mod 8"
(which it does).
Damnit, I'm
Michael G Schwern [EMAIL PROTECTED] writes:
[...]
I propose that this work out to
"The old lie\n Dulce et decorum est\n Pro patria mori.\n"
and always work out to that, no matter how far left or right the
expression be indented.
{ { { { {
if(
the prototype working with
Filter::Util::Call. I found myself needing to work line-by-line, and
that whole "build up $_" was getting in my way, so I switched to
Filter::Util::Exec and it works, but it makes debugging really hard.
=head1 NAME
RFC::Prototype::111 - Implements Perl 6 RFC 11
Michael,
I just noticed your post (I am at work). This is begining to get there (maybe I
should not have split the original
111).
In the prototype you only cover use of " quotes.
if( ($pre_code, $quote_type, $curr_tag, $post_code) = $_ =~
m/(.*)\\(")(\w+)"(.*)/ )
It needs to match
Glenn Linderman wrote:
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here do
Ariel Scolnicov wrote:
1. It requires the perl parser know about indentation. Of course we
all know that tabs are 8 characters wide (I myself make a point of
bludgeoning anyone who says otherwise), but do we really want to
open this can of worms?
Not so fast with those 8-column tabs.
In Michael Schwerns prototype, expansion to treat both semicolons and comments
at the end tag is possible by changing
/^(\s*)$curr_tag\s*$/
to
/^(\s*)$curr_tag\s*(;\s*)?(#.*)?$/
Richard
;
This is on the left margin.
This is indented one char.
FIRST_HERE_DOC
This is indented one char.
This is on the left margin.
SECOND_HERE_DOC
RFC 111 specifically disallows statements after the terminator
because it is too confusing. I would say that the same logic should apply
Show me where this fails and I'll shut up about it.
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Before you scream "Bloody murder",
At 10:52 AM 9/14/00 -0700, Nathan Wiger wrote:
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
I have thought this before, but I think the
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving
Nathan Wiger wrote:
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
Richard Proctor made some excellent comments, and asked:
When measuring whitespace how does the system treat tabs? (be realistic
and dont FLAME)
I suggest that there be NO tab/space conversion. Not 8 columns, not
4 columns, nothing. If the here doc terminator has four tabs preceding
it, then
Eric Roode wrote:
I suggest that there be NO tab/space conversion.
I also suggest that no whitespace stripping/appending/etc/etc be done at
all. If I write:
if ( $its_all_good ) {
print EOF;
Thank goodness this text is centered!
EOF
}
That should print
Nathan Wiger wrote:
I also suggest that no whitespace stripping/appending/etc/etc be done at
all. If I write:
[...deletia...]
But this shouldn't be implicit in the language.
That's a good argument for having a separate operator for these
"enhanced here docs", say , rather than chucking the
r better, its subsuming problem #3 to be solved.
OK: here's a dequote_like solution that solves it--the additional solution needed is
just to change perl6 to recoginze here-doc
terminators allowing leading/trailing white space. Which is what I suggested that RFC
111 be reduced to. dequote_like is avai
On Thu, 14 Sep 2000 10:52:16 -0700, Nathan Wiger wrote:
We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
With your above functions, you always need to be able to escape the
string end delimiter. Therefore, you will
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving
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
Nathan Wiger wrote:
Solves problem #1, indented terminator, except that it adds two newlines
(more later).
I never found anything later about these extra newlines... so if this idea
has merit, it needs to be finished.
However, it leaves 2 and 3. Let's try adding in a regexp:
if(
On Thu, Sep 14, 2000 at 10:52:16AM -0700, Nathan Wiger wrote:
Before you scream "Bloody murder", please read on...
I'll wait patiently for the end...
if( $is_fitting $is_just ) {
die subst /\s{8}(.*?\n)/$1/g, qq/
The old lie
Dulce et decorum est
Glenn Linderman wrote:
I think $mesg wins up with the value of "1" the way you've coded it.
Sorry, I missed the placement of the (). $mesg is fine.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
Michael G Schwern wrote:
No, it still has all the problems of any other regex-based solution.
If you shift the code right or left, it breaks (due to the \s{8}) and
you're back to counting whitespace again.
Y'know, I pointed out before why I think this is a superfluous issue.
You have to
On Thu, Sep 14, 2000 at 02:51:14PM -0700, Glenn Linderman wrote:
Michael G Schwern wrote:
Well, OK, so now we're talking shades of opinion. You'd agree it
works, though, and quite effectively. But you'd disagree about its
aesthetics, and its performance. The former is much less
Michael G Schwern wrote:
I'd prefer if here-docs just DWIM.
Yes, but... what do you mean vs. what do others mean, and all these
problems
Others can continue to put the here-doc tag flush left if they don't
want this behavior.
See, this is just too inflexible. The main
On 4 Sep 2000 21:32:00 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
[...]
=head1 IMPLENTATION
Intentional? It's either
I think it should be made explicit what happens if the here doc
terminator itself contains comment characters or semicolons. This is
my suggestion:
The here doc terminator must match as a string (that is,
Cm/^\s*\Q$term\E\s*(?:\#|;\s*$)/ should match the line, where $term is
the desired
On Mon, Sep 04, 2000 at 09:32:00PM -, Perl6 RFC Librarian wrote:
Perl6 should ignore any whitespace before the terminator of a heredoc on any
line.
Good. I don't see anything wrong with this.
***BRAIN STORM!***
RFC 162 (http://dev.perl.org/rfc/162.html) wanted to allow indented
Michael G Schwern wrote:
The RFC proposes a operator which would strip whitespace off the
front of the here-doc. Problem is preserving indentation. We can
merge the two.
Actually, the two started merged. :-) They were split up after there
were too many people for RFC 111 but against RFC
On Mon, Sep 04, 2000 at 05:36:32PM -0700, Nathan Wiger wrote:
Actually, the two started merged. :-) They were split up after there
were too many people for RFC 111 but against RFC 162. Personally, I'd
rather see the recipe method of:
print END_OF_DOC =~ s/^\s{0,5}//g;
This still leaves
This still leaves the problem of having to count whitespace and having
to change your regex if you reindent your code. In effect, it causes
whitespace to become significant. Bleh.
It's much better to use the Cookbook method: it stands out better.
Please observe.
--tom
Michael G Schwern wrote:
print END_OF_DOC =~ s/^\s{0,5}//g;
This still leaves the problem of having to count whitespace and having
to change your regex if you reindent your code. In effect, it causes
whitespace to become significant. Bleh.
How is this different from having to count
RFC162Filtering Heredocs (was originally part of RFC 111 V1)
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
Further it should ignore any whitespace (and comments) that follow the
terminator.
All of these should work:
print EOL ;
EOL # this is the end of the here doc
But currently, I like using:
print "#EOT#2";
blah
Bart Lateur [EMAIL PROTECTED] writes:
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
Further it should ignore any whitespace (and comments) that follow the
terminator.
All of these should work:
print EOL ;
EOL # this is the end of the here doc
But
Richard Proctor proposed:
All of these should work:
print EOL;
EOL
print EOL;
EOL
print EOL ;
EOL # this is the end of the here doc
People may throw rocks at me for this, but I'd like to suggest that
not only is a comment allowed on the terminator line,
On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote:
People may throw rocks at me for this, but I'd like to suggest that
not only is a comment allowed on the terminator line, but a semicolon
also be allowed. Vis:
print EOL;
EOL; # This should work, too
Let me throw the first
Bart Lateur wrote:
Next you'll propose that
print EOL;
blah
EOL; print "OK!\n";
should work too, and print "OK!\n" as well.
Why not?! This seems like a good thing. ;, #, or \n are all valid
end-of-lines for here string delimiters. Sounds easy enough, and
On Mon, 28 Aug 2000 08:46:25 -0700, Nathan Wiger wrote:
OTOH, what about this...
print EOL
blah
EOL;
which makes this a full blown statement (note the missing semicolon in
the first line)...
No it doesn't!
perl -e '
print EOF
Hello world!
EOF;
'
Can't
On Mon 28 Aug, Eric Roode wrote:
Richard Proctor proposed:
All of these should work:
print EOL;
EOL
print EOL;
EOL
print EOL ;
EOL # this is the end of the here doc
People may throw rocks at me for this, but I'd like to suggest that
not only
On Mon 28 Aug, Bart Lateur wrote:
On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote:
People may throw rocks at me for this, but I'd like to suggest that
not only is a comment allowed on the terminator line, but a semicolon
also be allowed. Vis:
print EOL;
EOL; # This
Next you'll propose that
print EOL;
blah
EOL; print "OK!\n";
should work too, and print "OK!\n" as well.
Yes why not, though it might be bad style.
Because it gains you nothing, and loses much.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Here Docs Terminators (Was Whitespace and Here Docs)
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 27 Aug 2000
Mailing List:
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
of the here doc
I don't think a special syntax is needed just for this. Make
this the default (so "print EOL" does this automatically).
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
At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote:
Okay, devil's advocate.
Paragraphs.
sub legal {
print FOO
Attention criminal slacker, we have yet
to receive payment for our legal services.
Love and kisses
FOO
}
I'm
I'm coming into this a bit late, so forgive me if this is impossible or
already dismissed, but what about
print qr/\s*FOO\s*/
Attention, dropsied weasel, we are
launching our team of legal beagles
straight for your scrofulous crotch.
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 qr/\s*FOO\s*/
Attention, dropsied weasel, we are
launching our team of legal beagles
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
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.
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
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 /\s*FOO\s*/ means
terminate on a line matching that pattern, then how can we also say whether
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
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
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
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote:
=head1 ABSTRACT
With a here doc print ZZZ; the ZZZ has to be at the start of a line and
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
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote:
With a here doc print ZZZ; the ZZZ has to be at the start of a line and
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.
"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
70 matches
Mail list logo
