> Date: Mon, 02 Dec 2002 06:58:12 -0500
> From: "Joseph F. Ryan" <[EMAIL PROTECTED]>
>
> =pod
>
> =head1 Strings
>
> 'The quick brown $animal'
> "The quick brown $animal"
This will not format correctly in POD. Either indent or put it in a
list.
> =head2 Non-Interpolating Constructs
>
> Non-Interpolating constructs are strings in which expressions do not
> interpolate, or expand. The one exception to this is that the
^
s/,//
> backslash character, \, will always escape the character that
> immediately follows the it.
^^^^
s/the //
Except in single-quoted heredocs. Something about that doesn't seem
right. I, personally, want single quotes and q[] to never use \
specially.
> The base form for a non-interpolating string is the single-quoted
> string: 'string'. However, non-interpolating strings can also be formed
> with the q() operator. The q() operator allows strings to be made with
> any non-space, non-letter, non-digit character as the delimeter instead
> of '. In addition, if the starting delimeter is a part of a paired
> set, such as (, [, <, or {, then the closing delimeter may be the
> matching member of the set. In addition, the reverse holds true;
> delimeters which are the tail end of a pair may use the starting item
> as the closing delimeter.
Perhaps it's best not to use q(), since () are not valid delimiters
anymore (see A4, I think).
> =over 3
> Examples:
>
> $string = 'string' # $string = 'string'
> $string = q|string| # $string = 'string'
> $string = q(string) # $string = 'string'
^ ^
Yoink.
> $string = q]string[ # $string = 'string'
> =back
>
> There are a few special cases for delimeters; specifically : and #.
> : is not allowed because it might be used by custom-defined quoting
s/is/are/; s/it/they/
> operators to apply a property; # is allowed, but there cannot be a
> space between the operator and the #. In addition, comments are not
> allowed within # delimeted expressions (for obvious reasons).
Yep. That's why () are not allowed, as they could mean an argument to
a modifier.
> =head3 Embedding Interpolated Strings
>
> It is also possible to embed an interpolating string within a non-
> interpolating string by the use of the \qq{} construct. A string
> inside a \qq{} constructs acts exactly as if it were an interpolated
> string. Note that any end-brackets, "}", must be escaped within the
> the \qq{} construct so that the parser can read it correctly.
I don't remember this from anywhere. Where was this discussed?
> =over 3
> Examples:
>
> @array = <one two three>; # @array = ('one', 'two', 'three');
> @array = <one <\> three>; # @array = ('one', '<>', 'three');
Naturally, you mean:
@array = <<one two three>>; # ...
...
> =head3 Interpolation Rules
>
> =over 3
>
> =item Scalars: C<"$scalar">, C<"$(expression)">
> Non-Reference scalars will simply interpolate as their value. $()
> forces its expression into scalar context, which is then handled as
> either a scalar or a reference, depending on how expression evaluates.
>
> =item Lists: C<"@list">, C<"@(expression)">
> Arrays and lists are interpolated by joining their list elements by the
> list's separator property, which is by default a space. Therefore, the
> following two expressions are equivalent:
s/separator <sp> property/.separator attribute/
> =over 3
> print "@list";
> print "" ~ @list.join(@list.separator) ~ "";
> =back
>
> =item Hashes: C<"%hash">, C<"%(expression)">
> Hashes interpolate by joining its pairs on its .separator property,
> which by default is a newline. Pairs stringify by joining the key and
> value with the hash's .pairsep property, which by default is a space.
> Note that hashes are unordered, and so the output will be unordered.
> Therefore, the following two expressions are equivalant:
Again, s:e/property/attribute/
> =item Subroutines and Methods: C<"&sub($a1,$a2)">, C<"$obj.meth($a)">
> Subroutines and Methods will interpolate their return value into the
> string, which will be handled in whichever type the return value is.
> Same for object methods. Note that parens B<are> required during
> interpolation so that the parser can disambiguate between object
> methods and object members.
Object methods I<are> object members. All attributes are private, but
accessors are auto-generated for you (if you don't say otherwise). So
I don't think parens should be required.
> =head3 Embedding non-interpolated constructs: C<\q{}>
>
> Similar to embedding an interpolated string within a non-interpolated
> string, it is possible to embed a non-interpolated string within a
> interpolated string with \q{}. Any characters within a \q{} construct
> are treated as if they were in an non-interpolated string.
And this is waaay down here away from \qq{}... why?
> =head2 Special Quoting
>
> =head3 Here-Docs
>
> A line-oriented form of quoting is based on the shell "here-document"
> syntax. Following a << you specify a string to terminate the quoted
> material, and all lines following the current line down to the
> terminating string are the value of the item. The terminating string
> may be either an identifier (a word), or some quoted text. If quoted,
> the type of quotes you use determines the treatment of the text, just
> as in regular quoting. An unquoted identifier works like double quotes.
> The terminating string must appear by itself, and any preceding or
> following whitespace on the terminating line is discarded.
>
> =over 3
> Examples:
>
> print << EOF;
> The price is $Price.
> EOF
>
> print << "EOF"; # same as above
> The price is $Price.
> EOF
>
> print << "EOF"; # same as above
> The price is $Price.
> EOF
>
> print << `EOC`; # execute commands
> echo hi there
> echo lo there
> EOC
>
> print <<"foo", <<"bar"; # you can stack them
> I said foo.
> foo
> I said bar.
> bar
>
> myfunc(<< "THIS", 23, <<'THAT');
> Here's a line
> or two.
> THIS
> and here's another.
> THAT
You didn't mention that <<'THAT' doesn't interpolate.
>
> If you use a here-doc within a delimited construct, such as in s///eg,
Ummm, s:e//$()/
And that's interesting, as the rule might not still hold.
> the quoted material must come on the lines following tvhe final
> delimiter. So instead of:
>
> =over 3
> s/this/<<E . 'that'
> the other
> E
> . 'more '/eg;
> =back
>
> you have to write
>
> =over 3
> s/this/<<E . 'that'
> . 'more '/eg;
> the other
> E
> =back
>
> Also note that with single quoted here-docs, backslashes are not
> special, and are taken for a literal backslash, a behaivor that is
> different from normal single-quoted strings.
Yes. Shoulda mentioned that a long time ago, IMO.
Nice work.
Luke
