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
