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
On Fri 15 Sep, Michael G Schwern wrote:
On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote:
1) removes whitespace equivalent to the terminator (e) this is largely
backward complatible as many existing heredocs are unlikely to have white
space before the terminator.
2)
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 to allow whitespace
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(
I've implemented a prototype of the indented here-doc tag I'm proposing.
http://www.pobox.com/~schwern/src/RFC-Prototype-0.02.tar.gz
Its RFC::Prototype::111, which is probably the wrong number.
I'll have to add POD =~ s/// syntax. Also, if anyone's good with
filters I couldn't quite get the
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 docs I see in this RFC
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
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
Michael G Schwern wrote:
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"
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
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
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: 2 Sep 2000
Mailing List:
43 matches
Mail list logo
