>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 didn
>'!' bit. So I'm not sure how you'd have written that if you'd have done
>specification.
Yeah, ok. I still think
# Your stuff that you w
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 < !The old lie
> ! Dulce et decorum est
> ! Pro patria mori.
> P
>OK: here's a dequote_like solution that solves it--the additional soluti
>terminators allowing leading/trailing white space. Which is what I sugg
>perl5, but would require shoving "POEM" to the left margin and ensuring
>dequote Tom posted, with minor changes, and is given below. Maybe Tom c
>i
>This is the problem that currently here-doc content must be relative to
>indented code.
>> 2 Preserving sub-indentation.
>This is not _currently_ a problem. Perl _currently_ preserves indentati
>the way, that this problem is a problem. If problem 1 were solved by in
>the HERE document, t
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 thin
Certainly I could live with this set of suggestions. The complete set. Thanks
Richard and Michael for developing them.
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) <<<
On Fri, 15 Sep 2000 08:13:26 -0400 (EDT), Eric Roode wrote:
>The here-doc terminators all line up with the perl code.
>The generated program is nicely indented relative to the left margin.
My sentiments exaclty.
I think I would compare this to normal TV programmes (the code)
interruped by spec
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 Dulce et decorum est
> Pro patria mori.
>POEM
> }
>
>I propo
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 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.
>
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) <<< removes whitespace equivalent to the s
On Fri 15 Sep, Nathan Wiger wrote:
> Michael G Schwern wrote:
> > So indenting the terminator and indenting the text are linked. If you
> > do one, you want to do the other.
>
> As I and many others have said, that's not necessarily true. I like all
> my code to line up, braces, parens, and all.
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 < I don't know what their
> gripe is. A critic is
> simply someone paid to
>
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 gripe is. A critic is
>simply someone paid to
>render opinions
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
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_D
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 ma
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
> intere
Michael G Schwern wrote:
> 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
On Thu, Sep 14, 2000 at 01:30:15PM -0700, Nathan Wiger wrote:
> Y'know, I pointed out before why I think this is a superfluous issue.
> You have to either change your regexp, or change the indentation of your
> here docs terminator when you move your code around.
I think it would be best for us
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
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
__
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
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( $i
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 o
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 al
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
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 th
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 <
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 f
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
lan
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 RFC111
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
> 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", pleas
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
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
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
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 (.*)<<(
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 < be expanded.
2. POD end tags may now be followed by trailing whitespace
--
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(
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'
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 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 'IMPL
Michael G Schwern wrote:
>
> >print <
> 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 the number of spaces y
>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
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 < > I can't think of much else I'd want to c
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 agains
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
here-d
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,
C should match the line, where $term is
the desired terminator.
Otherwise the behaviour o
49 matches
Mail list logo
