Jon Lang wrote:
Thom Boyer wrote:
That seems better to me than saying that there's no tab character in
say "blah $x\t blah"
Whoever said that?
Oops. I thought Larry did. But he didn't; I misread it. Whew.
Somehow I managed to read Larry's words and get exactly the *opposite*
meaning from what he actually wrote:
Larry Wall wrote:
> This may also simplify the parsing rules inside double quoted
> strings if we don't have to figure out whether to include postfix
> operators like .++ in the interpolation. It does risk a visual
> clash if someone defines postfix:<t>:
> $x\t # means ($x)t
> "$x\t" # means $x ~ "\t"
How embarrassing. Thanks for asking "Whoever said that?", because it
forced me to go reread it.
I think I'd better go reread the whole thing. More carefully this time.
> Thom Boyer wrote:
>> when (if I understand correctly) you could write that as simply as
>> 1,2,3 say
> Nope. This is the same situation as the aforementioned '++' example,
> in that you'd get into trouble if anyone were to define an infix:<say>
OK. Let me see if I get this. First, let me state my understanding of
the issue with ++ (where ++ is actually a stand-in for *any* operator
that is both postfix and infix):
$x++ # postfix operator, because there's no whitespace
$x.++ # postfix (the dot is optional)
$x ++ # infix operator, because there's whitespace
$x\ ++ # postfix: space isn't allowed, but unspace is
$x\ .++ # postfix (the dot is still optional)
($x)++ # no whitespace, so postfix?
is ++ postfix, or infix?
Now, I think that
is a method call, even if there's a postfix:<foo> declaration in scope.
And that's a problem, because, no matter what precedence postfix:<foo>
is still going to mean
1, 2, (3.foo)
instead of the desired
so Larry has proposed
1,2,3\foo # means: postfix:<foo>(1, 2, 3)
as a way to get the desired meaning without having to resort to parentheses.
So the point is that a nospace unspace acts like dot, in that it turns
the following operator into a postfix operator. But it doesn't have the
undesired characteristic that it turns an intended postfix operator into
a method dispatch. Have I got that right, or am I still wandering in a
wilderness that is completely disconnected from Larry's proposal?
Final question: I think these are all equivalent. Are they?