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>
> operator.

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)

Question: given

    ($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> was given,


is still going to mean

    1, 2, (

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?



Reply via email to