I'm unsure what the outcome of the recent long dot discussions is
as far as the range operator is concerned. Since the whole point
of the long dot is to support alignment styles the following cases
shouldn't mean different things:

    foobar     #0  single call to foobar (OK, that is different)
    foo.bar    #1  method .bar on retval of foo
    foo..bar   #2  range from retval of foo to retval of bar?
    foo. .bar  #3  same as #1

    $x++       #0
    $x.++      #1
    $x..++     #2  or: $x. ++?
    $x. .++    #3

    foo()      #0
    foo.()     #1
    foo..()    #2
    foo. .()   #3

Are all the #2 cases valid syntax? Does the range operator
need whitespace then? Or is there a hole for spacing level 2?

BTW, the above dot sequences let the successions of long dots
look like a wedge, so there are some merits in the idea.
But isn't forced whitespace on the range too high a price?
--

.. is always the range operator.  The "dot wedge" just has a discontinuity
in it there.  I can't think of any wedgey applications that wouldn't work
about as well by starting the wedge with $x. .y instead of $x.y.

Larry

    foo.  .bar;
    self. .bar;

instead of

    foo .bar;
    self.bar;

with the rules as before long dot was invented. Why are calls
on the topic so important? Wouldn't it be cleaner to force
a leading zero in numeric literals?

I might be to blind to see it, but could someone give some
examples where the cleanliness of the new parsing is obvious?
I mean compared to the old rules, not counting intended calls
on topic.
--

         foo.bar;
        self.bar;

I *still* don't understand the problem this long dot is trying to solve.

-- c

$query
.fetchrow($i)
.selectcolumn($j)
.say;

rather than

$query.
fetchrow($i).
selectcolumn($j).
say;

but surely

$query.
.fetchrow($i).
.selectcolumn($j).
.say;

is the worst of both worlds? And it strikes me that the ability to put
big, block comments between operator and operand is not a particularly
useful one.

--
"Of all  things,  good sense is  the most fairly  distributed:  everyone
thinks  he is  so well  supplied  with it  that even  those who  are the
hardest to satisfy in  every other respect never  desire more of it than
they already have."   --  Descartes, 1637      http://surreal.istic.org/

application_pgp-signature_part < 1K Download

It's trying to solve the fundamental ambiguity of:

     foo .bar

Which might be:

     foo().bar

or might be:

     foo(.bar)

The way we solved it is by saying that, anywhere a term is expected, a
sequence matching:

     /\s+ \. [<ident>|<brackets>]/

is always a unary dot method call.

The reason we chose that is because we think that things like this:

     method describe {
         say .name;
         say .rank;
         say .serial_num;
     }

and this:

     given %data {
         .<name> = join .<sep>, ucfirst .<first>, uc .<family>
     }

will be common. And that it's much easier to understand such constructs if a
"gappy dot" *always* means unary dot, regardless of what preceded it.

That leaves a problem for people who want to line up method calls, or cascade
them over multiple lines. So we need a way to indicate that a "gap-dot"
doesn't mean unary method call. Which means we need a way to prevent perl6
from expecting a term, where a term is normally expected. Which we chose to do
by providing a postfix that indicates "more expression to come yet" or "don't
switch back to expecting a term here".

And the postfix Larry decided upon (rightly, I believe) was dot.

Damian