Two points, if I may jump in here:
(1) If the interpolation rule is to be simple as suggested, why not impose this rule:
"A character (except for a backslash) is interpreted literally if it is not preceeded by a backslash."
For example,
"The value is \$foo.bar()." --> "The value is 3." "The value is $foo.bar()." --> 'The value is $foo.bar().'
"The value is \{1+2}." --> "The value is 3."
"The value is {1+2}." --> "The value is {1+2}.""[EMAIL PROTECTED]" --> '[EMAIL PROTECTED]' "[EMAIL PROTECTED]" --> '[EMAIL PROTECTED]'
"$19.95" --> '19.95' "\$x" --> '3'
"%08x" --> '%08x' "\%y" --> '1 2 3 4' (or something)
(2) It seems that qq// and {} are on "equal footing" and should be treated orthogonally. So, you could nest {} into qq// as such:
qq( The value is {1+1}. )or vice-versa:
{ $x = qq(The value is) . (1+1) }or nest each into itself, such as quotes inside quotes, such as (something like) this:
qq(
<style>
div \{ color : { $yes ? 'blue' : 'white' } \}
</style>
q[ Just $19.95! ]
)so as not to require another level of {}: qq( ... { q[ Just $19.95! ] })Further, {} should be able to use any bracket type, just as qq// can take the forms qq(), qq{}, qq<>, etc. Something like this:
qq(
<style>
div { color : e[ $yes ? 'blue' : 'white' ] }
</style>
e< '{' x 4 >
q[ Just $19.95! ]
e< '}' x 4 >
)Under my first proposal, this is rewritten unambiguously as
qq(
<style>
div { color : \e[ $yes ? 'blue' : 'white' ] }
</style>
\e< '{' x 4 >
Just $19.95!
\e< '}' x 4 >
)-davidm
Larry Wall wrote:
On Tue, Jul 20, 2004 at 09:20:56PM -0400, Damian Conway wrote:
: So what about:
: : $foo[$i]
: $foo{$k}
: : ???
Those would work.
: And would slices interpolate?
Yes. Slices are entirely determined by what's in the subscript.
: I can't say I'm keen on making {...} special in strings.
It had to grow on me a while too.
: I felt that the $(...) and @(...) were a much cleaner and more : general solution.
Yeah, I felt that way too. But then I start looking at teaching people the subtle difference between
${} $() @{} @() %{} %() ? &{} &() ???
and realize that this is the only holdover from Perl 5 where we use the sigil to indicate the internal context rather than the type of the object expected. It's a danger sign that we have to keep repeating ourselves (or not, as the case may be):
$($foo) @(@foo) $(@foo)
Plus it ignores the fact that we've already introduced single character scalar context operators that make it trivial to coerce from list context to scalar. If {...} supplies list context by default, most intepolations are either the same length or shorter:
$($foo) {$foo} @(@foo) [EMAIL PROTECTED] $(@foo) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
It also encourages people be more specific about *which* scalar context they're looking for. It fits in with the general trend in Perl 6 that the "default" context is list context if you don't know better.
Plus, as I mentioned, it cleans up the "$file.ext" mess, the "[EMAIL PROTECTED]" mess, and the "%08x" mess. That's three FAQs that don't have to exist.
: The prospect of backslashing every opening brace in every interpolated string : is not one I relish.
I'm just looking for what will be least confusing to the most people here. We can certainly have other possible behaviors, but something simple needs to be the default, and $() doesn't feel right to me anymore.
Larry
