Re: $a.foo() moved?

2006-04-07 Thread TSa

HaloO,

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


$a.foo() moved?

2006-04-06 Thread Matt Fowles
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?

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


Re: $a.foo() moved?

2006-04-06 Thread Larry Wall
On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote:
: 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


Re: $a.foo() moved?

2006-04-06 Thread Matt Fowles
Larry~

On 4/6/06, Larry Wall [EMAIL PROTECTED] wrote:
 On Thu, Apr 06, 2006 at 01:58:55PM -0400, Matt Fowles wrote:
 : 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.

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.

Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary


Re: $a.foo() moved?

2006-04-06 Thread Larry Wall
On Thu, Apr 06, 2006 at 02:35:53PM -0400, Matt Fowles wrote:
: 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/\.+ \sws 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/ [ \.+ \sws ]+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


Re: $a.foo() moved?

2006-04-06 Thread John Macdonald
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/\.+ \sws 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 infixexactly
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. :-)

-- 


Re: $a.foo() moved?

2006-04-06 Thread Patrick R. Michaud
On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
 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/\.+ \sws before \./ lets you embed
  arbitrary whitespace, comments, pod, etc, within the postfix operator.
  
 
 The one quibble I see with this is that postfix one or more
 dots, including 3 might be a touch confusing with infixexactly
 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


Re: $a.foo() moved?

2006-04-06 Thread John Macdonald
On Thu, Apr 06, 2006 at 02:49:33PM -0500, Patrick R. Michaud wrote:
 On Thu, Apr 06, 2006 at 03:38:59PM -0400, John Macdonald wrote:
  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/\.+ \sws before \./ lets you 
   embed
   arbitrary whitespace, comments, pod, etc, within the postfix operator.
   
  
  The one quibble I see with this is that postfix one or more
  dots, including 3 might be a touch confusing with infixexactly
  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).

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.

--