On 26 Oct 2002, Smylers wrote: : Larry Wall wrote: : > I'm thinking we need a rule that says you can't put a space before a : > dereferencing (...), : : I'm concerned that making this sensitive to whitespace doesn't simplify : things. : : > print(length $a), "\n"; : > print (length $a), "\n"; : : Those look to me like they should do the same thing as each other.
Sorry, they don't look that way to me. : Distinguishing them sounds scary, much scarier than having C<$a _ 1> : being different from C<$a_1>. But we already have exactly the same distinction with $foo{ $bar } $foo { $bar } not to mention $a ?? $foo::bar $a ?? $foo :: bar : How much is the 'if it looks like a function it is a function' rule : needed at all? What would be the harm in not having any special rule : here, so both of the above pass the line-break to C<print>? The harm would be that we'd basically be reinventing Lisp syntax with precedence in place of some of the parens. : Somebody : needing to ensure that C<print> only got one argument could do: : : (print length $a), "\n"; : : That is, parens always go round the outside of the thing they are : grouping even when the thing is a function call. You're also bringing that parenthesis all the way out to the front of: ($obj.foo.bar.baz[3]{"finagle"}.each.subobj.print length $a), "\n"; That's not so good. Unless you make method syntax different from functions. Which is also not so good. : That would be counter-intuitive to anybody coming from a background in a : language where parens have to be used in all function calls, but: : : 1 It has the benefit of there being one simple rule to learn, with no : caveats about functions (or whitespace). Even when somebody gets it : wrong, it's a case of showing how the general rule should be applied : in this particular case rather than introducing an exception; that : should be easier to learn. Lisp has one simple rule to learn too. :-/ And I don't think this is introducing another exception when we're talking about generalizing it for all brackets, and maybe all operators that can have both a postfix and some non-postfix meaning. : 2 There's no need to have any sort of disambiguating character (like : the current C<+> or the suggested C<.> (with opposite meanings)). At the cost of requiring *two* separate disambiguating characters in many cases, one of which is a long way away from the "action". To put it another way, these kinds of disambiguating characters break up the left-to-right reading. This is the sort of thing we're trying to get away from already. Perl 5 had the problem with braces: Perl 5: @{ foo($x) }[1,2,3] Perl 6: foo($x)[1,2,3] : 3 If somebody wants to put parens after all her/his function names : they often won't do any harm. Until they write print rand(3), "\n" and wonder why they're getting print rand(3, "\n") : I don't think the default situation : for somebody who doesn't know the rules is made worse. There are : some situations made 'worse', and some, like the above, made : 'better'. Well, here I'd trot out Simon's argument that most of the people will be coming from C-ish background, not Lispish background. Counting by "situations" doesn't take into account the fact that I'd be lynched by several million people if I did that. I do think that "." may be the wrong character to "eat" whitespace though. $hash .[$key] $hash _[$key] Reminds me of the old problem of what to use if we adopted the rule I keep hankering for that says a final } on a line ends the current statement. A _ could be made to suppress whitespace interpretation there too, only on the other end of the bracket: $x = do { foo(); bar(); baz() }_ + 2; (That _ would presumably *not* turn the following operator into a postfix.) Using _ rather than . would prevent it from being interpreted as a method call. That might be particularly important with alphanumeric operators. $x .x # the .x method $x _x # the x postfix operator The definition of a factorial could then be sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1)! } (assuming decent tail-recursion optimization). Note that since the syntax is implied by the name, the newly defined operator can be used within the body. But this would be a syntax error: sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) ! } which could be fixed with the _: sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) _! } Weird, but it's all consistent with the distinction we're already making on curlies, which gave a great increase in readability. And it would let someone declare a ++ binary operator if they wanted it. print $a++ ++ ++$b; Whatever that means... :-) Larry