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 going to continue beating this horse until it stops twitching.


Tom and I had an extensive off-list discussion about this, and here's
about where it left off (hopefully I'll get everything right).

We have three major problems and three proposed solutions:

    Problems:
    1 Allowing here-docs to be indented without effecting the ouput.
    2 Preserving sub-indentation.
    3 Preserving the output of the here-doc regardless of how its
      overall indentation is changed (ie. shifted left and right)

    Solutions
    1 <<POD =~ s/some_regex//
    2 dequote(<<POD)
    3 indentation of the end-tag

Each solution has their strengths and weaknesses.  Regexes can handle
problem #1 but only #2 xor #3.  However, they cover a wide variety of
more general problems.  dequote has the same problem.  #1 is fine, but
it can only do #2 xor #3.  Not both.

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 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( $is_fitting && $is_just ) {
                die <<POEM;
                    The old lie
                  Dulce et decorum est
                      Pro patria mori.
                POEM
   } } } } }
        
Four spaces, two spaces, six spaces.  Makes sense, everything lines
up.  So far I have yet to see a regex or dequote() style proposal
which can accomdate this.


So solution #1 is powerful, solution #2 is simple, solution #3 solves
a set of common problems which the others do not (but doesn't provide
the other's flexibility).  All are orthoganal.  All are fairly simple
and fairly obvious.  Allow all three.


My most common case for needing indented here-docs is this:

    {   {   {   {  # I'm nested
                    if($error) {
                        warn "So there's this problem with the starboard warp coupling 
and oh shit I just ran off the right margin.";
                    }
    }   }   }   }

Usually I wind up doing this:

    {   {   {   {  # I'm nested
                    if($error) {
                        warn "So there's this problem with the starboard ".
                             "warp coupling and oh shit I just ran off the ".
                             "right margin.";
                    }
    }   }   }   }

I'd love it if I could do this instead:

    {   {   {   {  # I'm nested
                    if($error) {
                        warn <<ERROR =~ s/\n/ /;
                        So there's this problem with the starboard warp
                        coupling and hey, now I have lots of room to
                        pummell you with technobabble!
                        ERROR
                    }
    }   }   }   }

By combining two of the solutions, my problem is solved.  I can indent
my here-docs and yet keep the output a single line.

Show me where this fails and I'll shut up about it.


-- 

Michael G Schwern      http://www.pobox.com/~schwern/      [EMAIL PROTECTED]
Just Another Stupid Consultant                      Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
          - Unknown narrator speaking about Anime

Reply via email to