Re: Captures: Synopsis update
On 9/21/06, Larry Wall <[EMAIL PROTECTED]> wrote: A method never takes arguments unless you use : or (), so those are all infix. Well, all righty then. Yay for unambiguity! Or disambiguation. Or nonambiguosity. Or whatever... The design team worked Really Hard to get rid of that particular ambiguity in Perl 6. Thank you, design team. -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Captures: Synopsis update
On Thu, Sep 21, 2006 at 12:16:26PM -0400, Mark J. Reed wrote: : Which means that argumentless subroutine calls will presumably be rare : in P6 code, but what about methods? Methods with no arguments (apart : from the invocant) will always be commonplace, and it seems to me that : you have exactly the same ambiguity there: : : $o.a%$b : $o.a % $b : $o.a %$b A method never takes arguments unless you use : or (), so those are all infix. The design team worked Really Hard to get rid of that particular ambiguity in Perl 6. Argumentless methods parse more like variables than like functions. Incidentally, this is why all the optional arg functions that default to $_ turned into methods, so you have use .print if you want to print $_ by default. Unlike a bare "print", a ".print" doesn't expect more arguments unless you put : or (), so it simplifies parsing greatly. Larry
Re: Captures: Synopsis update
On 9/21/06, Larry Wall <[EMAIL PROTECTED]> wrote: : note how the ambiguity of the following are resolved: : : a|$b : a | $b : a |$b : Don't think so. The situation is exactly analogous to: a%$b a % $b a %$b The cultural ambiguity is also being reduced insofar as we're trying to discourage use of bare constants in favor of sigilled constants. Which means that argumentless subroutine calls will presumably be rare in P6 code, but what about methods? Methods with no arguments (apart from the invocant) will always be commonplace, and it seems to me that you have exactly the same ambiguity there: $o.a%$b $o.a % $b $o.a %$b -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Captures: Synopsis update
On Thu, Sep 21, 2006 at 10:29:57AM -0400, Aaron Sherman wrote: : I'll read that as "conversation terminated". The conversation is never terminated. However, every now and then I make feeble attempts to be decisive. :) : Can you please update S03's "Junctive operators" section to note how the : ambiguity of the following are resolved: : : a|$b : a | $b : a |$b : : I presume that it will be based on whitespace, but they could also be : based on an inspection of a's signature (if a takes no parameters, then : the only useful meaning of C is C(a(), $b)>, I think). There's no whitespace dwimmery here. Either 'a' takes an argument list or it doesn't, based on its signature. If it doesn't, all those are infix:<|>. If it does, they are all prefix:<|>, except that we specifically outlaw the first; list operators in Perl 6 require a space after them. : I further presume that such an update will be required for the pugs/v6 : team to correctly implement this. Don't think so. The situation is exactly analogous to: a+$b a + $b a +$b and even more exactly analogous to: a%$b a % $b a %$b The cultural ambiguity is also being reduced insofar as we're trying to discourage use of bare constants in favor of sigilled constants. If you see a bare function name you should generally assume it has arguments in Perl 6. We could probably go as far as to issue an optional warning on the middle cases above based on whitespace dwimmery and on whether the program gets in trouble later. But it would be a mistake to base the actual parsing on that. That's the sort of trick Perl 5 would have attempted, and I hope I know better now. Larry
