foo..bar or long dot and the range operator
TSa
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?
--
Larry Wall
: I'm unsure what the outcome of the recent long dot discussions is
: as far as the range operator is concerned.
.. 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
TSa
Doesn't that discontinuity devalue the long dot? Its purpose is
alignment in the first palce. For a one char diff in length one
now needs
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.
--
Chromatic
> Doesn't that discontinuity devalue the long dot? Its purpose is
> alignment in the first palce. For a one char diff in length one
> now needs
>
> foo. .bar;
> self. .bar;
>
> instead of
>
> foo .bar;
> self.bar;
Or even:
foo.bar;
self.bar;
I *still* don't understand the problem this long dot is trying to solve.
-- c
Daniel Hulme
> solve.
I'm a bit with you, there. I can see why you might want to do
$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/
Damian Conway
> I *still* don't understand the problem this long dot is trying
> to solve.
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