Re: foo..bar or long dot and the range operator

[TSa]

HaloO,

Larry Wall wrote:

On Tue, Apr 11, 2006 at 12:41:30PM +0200, TSa wrote:
: 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.


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

Re: foo..bar or long dot and the range operator

[chromatic]

On Wednesday 12 April 2006 00:06, TSa wrote:

 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

Re: foo..bar or long dot and the range operator

[Daniel Hulme]

 I *still* don't understand the problem this long dot is trying to
 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/


pgpv07fAWYXKZ.pgp
Description: PGP signature

Re: foo..bar or long dot and the range operator

[Damian Conway]

TSA wrote:

 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

Re: foo..bar or long dot and the range operator

[Larry Wall]

On Tue, Apr 11, 2006 at 12:41:30PM +0200, TSa wrote:
: 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