$a.foo() moved?
Matt Fowles
I just noticed something claiming that C<$a. foo()> is actually
C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually
C<$a $_.foo()> (likely a syntax error).
When did this change? Why did this change?
Also, I liked it better when C<$a .foo()> was a method call on C<$a>.
Thanks,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Larry Wall
: All~
:
: I just noticed something claiming that C<$a. foo()> is actually
: C<$a.foo()> (a method call on C<$a>) and that C<$a .foo()> is actually
: C<$a $_.foo()> (likely a syntax error).
:
: When did this change? Why did this change?
It changed at the last hackathon, but is still being debated, mostly
on #perl6. The current S02 "early dot" rule is likely being abandoned,
but we don't know for what yet. The reason is that term/operator
lexer state is interacting badly with inconsistent retroactive
whitespace cancellation.
: Also, I liked it better when C<$a .foo()> was a method call on C<$a>.
Sure, that one might be obvious, but quick, tell me what these mean:
say .bar
say .()
say .1
when .bar
when .()
when .1
foo .bar
foo .()
foo .1
.foo .bar
.foo .()
.foo .1
I'd rather have a rule you don't have to think about so hard. To me
that implies something simple that let's you put whitespace *into*
a postfix without violating the "postfixes don't take preceding
whitespace" rule.
Larry
Matt Fowles
That makes a good deal of sense. I don't know what I would like more,
so I guess that I will wait till a more firm consensus is reached.
Larry Wall
: That makes a good deal of sense. I don't know what I would like more,
: so I guess that I will wait till a more firm consensus is reached.
The current consensus on #perl6 is that, in postfix position only (that
is, with no leading whitespace), m:p/\.+ \s<ws> <before \.>/ lets you embed
arbitrary whitespace, comments, pod, etc, within the postfix operator.
This allows both the short
:foo. .()
as well as the longer
$x...
.foo()
Or possibly m:p/ [ \.+ \s<ws> ]+<before \.>/, which would let you intermix as
many dots into the whitespace as you like:
$x. . . . . .()
But that's a little out there. In any event $x..$y is still a range
because there's no whitespace after .. and $x .. $y is still a range
*because* there's whitespace before. The only casualty is $x... with
trailing whitespace can't mean $x..Inf. But you almost always want to
put something like a comma or bracket after it anyway.
And the nice thing is that it becomes a drop-dead simple rule that
postfix operators never, ever have leading whitespace, and you can always
distingish an infix operator from a postfix by whitespace. No more
retroactive guessing games.
It's possible the $x... infinite range operator could be recast to
something else like $x..* or some such, but that's a niggle compared
to the enormity of cleaner parsing.
Larry
John Macdonald
> The current consensus on #perl6 is that, in postfix position only (that
> is, with no leading whitespace), m:p/\.+ \s<ws> <before \.>/ lets you embed
> arbitrary whitespace, comments, pod, etc, within the postfix operator.
>
> This allows both the short
>
> :foo. .()
>
> as well as the longer
>
> $x...
> .foo()
The one quibble I see with this is that postfix <one or more
dots, including 3> might be a touch confusing with infix<exactly
3 dots> (i.e. the yada operator). Depending upon context
"..." can thus be either an error (code not yet written)
or layout control and valid to "execute" (I put execute in
quotes because by the time you get around to executing the
code the ... will have served it purpose of controlling the
parsing and be gone).
(This is just the one-shot "I'm not used to it yet" vote. :-)
--
Patrick R. Michaud
> On Thu, Apr 06, 2006 at 12:10:18PM -0700, Larry Wall wrote:
> > The current consensus on #perl6 is that, in postfix position only (that
> > is, with no leading whitespace), m:p/\.+ \s<ws> <before \.>/ lets you embed
> > arbitrary whitespace, comments, pod, etc, within the postfix operator.
> >
>
> dots, including 3> might be a touch confusing with infix<exactly
> 3 dots> (i.e. the yada operator).
There isn't an infix:<...> operator. There's
term:<...> ("yada yada yada"), and there's
postfix:<...> ("$x..Inf").
Pm
John Macdonald
Hmm, yep I got the terminology wrong, but my point remains -
one operator that is "...", exactly 3 dots, and another that
can be "..." but can be spelled with a different number of
dots if you feel like it, is somewhat confusing.
--
TSa
Larry Wall wrote:
> Sure, that one might be obvious, but quick, tell me what these mean:
>
> say .bar
> say .()
> say .1
> when .bar
> when .()
> when .1
> foo .bar
> foo .()
> foo .1
> .foo .bar
> .foo .()
> .foo .1
>
> I'd rather have a rule you don't have to think about so hard. To me
> that implies something simple that let's you put whitespace *into*
> a postfix without violating the "postfixes don't take preceding
> whitespace" rule.
To me your examples fall into three categories that are distinguished
by the type of characters following the dot
.bar # identifier --> postfix method
.() # parens --> postfix invocation
.1 # number literal
From there on the difficulty comes not from the syntax but the
intended semantics! E.g. the non-whitespace when(), when.() and
when.bar are syntax errors, right? So why should the whitespace
version suddenly mean invocation or dispatch on topic?
The only thing that bothers me is that more parens and explicit
$_ will be needed. E.g. say (.bar) or say $_.bar in the first triple.
And the compiler has to know something about the bare foo. Apart
from that the syntactic rules are simple.
--