[svn:perl6-synopsis] r10077 - doc/trunk/design/syn
la...@cvs.perl.org
Date: Mon Jul 10 13:48:24 2006
New Revision: 10077
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
Disallow postfix after listops without intervening (), .() or \.().
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Mon Jul 10 13:48:24 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 10 Aug 2004
- Last Modified: 1 July 2006
+ Last Modified: 10 July 2006
Number: 2
- Version: 48
+ Version: 49
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -1713,8 +1713,8 @@
If it is not, it is compiled as a provisional function call of
the list operator form, which may or may not have an argument list.
When in doubt, the attempt is made to parse an argument list. As with
-any list operator, an immediate postfix operator means there are no
-arguments, whereas anything following whitespace will be interpreted
+any list operator, an immediate postfix operator is illegal unless it is a
+form of parentheses, whereas anything following whitespace will be interpreted
as an argument list if possible.
Based on the signature of the subroutine declaration, there are only
@@ -1747,16 +1747,16 @@
or a method call in dot form. (It is also allowed on a label when a
statement is expected.) So for any undeclared identifier "C<foo>":
- foo.bar # foo().bar -- postfix prevents args
+ foo.bar # foo().bar -- illegal postfix, must use foo().bar
foo .bar # foo($_.bar) -- no postfix starts with whitespace
- foo\ .bar # foo().bar -- long dot, so postfix
- foo++ # foo()++ -- postfix
+ foo\ .bar # foo().bar -- illegal long dot, use foo()\ .bar
+ foo++ # foo()++ -- illegal postfix, must use foo()++
foo 1,2,3 # foo(1,2,3) -- args always expected after listop
foo + 1 # foo(+1) -- term always expected after listop
foo; # foo(); -- no postfix, but no args either
foo: # label -- must be label at statement boundary.
-- illegal otherwise
- foo: bar: # two labels in a row
+ foo: bar: # two labels in a row, okay
.foo: # $_.foo: 1 -- must be "dot" method with : args
.foo(1) # $_.foo(1) -- must be "dot" method with () args
.foo # $_.foo() -- must be "dot" method with no args
Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Mon Jul 10 13:48:24 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 8 Mar 2004
- Last Modified: 1 Jul 2006
+ Last Modified: 10 Jul 2006
Number: 3
- Version: 44
+ Version: 45
=head1 Changes to existing operators
@@ -224,18 +224,23 @@
syntax.
=item * List operators are all parsed consistently. As in Perl 5,
-to the left they look like terms, while to the right they look like
-operators that are looser than comma. Unlike in Perl 5, the difference
+to the left a list operator look like term, while to the right it looks like
+an operator that is looser than comma. Unlike in Perl 5, the difference
between the list operator form and the function form is consistently
indicated via whitespace between the list operator and the first
argument. If there is whitespace, it is always a list operator,
-and the next token will be taken as the first term of the list.
-If there is no whitespace, the parser is biased towards taking the
-next token as an operator if at all possible. If the next token
-can be taken as either an infix or a postfix operator, it indicates
-that the list operator has no arguments. (Or more precisely, no
-extra arguments that aren't supplied the operator, since C<.()>
-is a postfix that supplies arguments to the preceding function.)
+and the next token will be taken as the first term of the list (or
+if there are no terms, as the expression terminator).
+
+If there is no whitespace, the operator is never taken as a list
+operator, but always as a functional operator. Postfixes are
+specifically disallowed right after the operator except for the
+parenthetical forms delimiting the argument list. The parentheses
+are optional if and only if there are no arguments. If there are
+parentheses, they may be followed by any postfix operator. Unlike
+postfix operators, infix operators and expression terminators are
+allowed without intervening whitespace, and will be taken to indicate
+that the operator is a function with no arguments.
Examples:
@@ -244,18 +249,18 @@
say foo ($bar+1),$baz say(foo($bar+1, $baz));
say foo .($bar+1),$baz say(foo($_.($bar+1), $baz));
- say foo[$bar+1],$baz say((foo[$bar+1]), $baz);
- say foo.[$bar+1],$baz say((foo[$bar+1]), $baz);
+ say foo[$bar+1],$baz illegal, need foo()[]
+ say foo.[$bar+1],$baz illegal, need foo().[]
say foo [$bar+1],$baz say(foo([$bar+1], $baz));
say foo .[$bar+1],$baz say(foo($_.[$bar+1], $baz));
- say foo{$bar+1},$baz say((foo{$bar+1}), $baz);
- say foo.{$bar+1},$baz say((foo{$bar+1}), $baz);
+ say foo{$bar+1},$baz illegal, need foo(){}
+ say foo.{$bar+1},$baz illegal, need foo().{}
say foo {$bar+1},$baz say(foo({$bar+1}, $baz));
say foo .{$bar+1},$baz say(foo($_.{$bar+1}, $baz));
- say foo<$bar+1>,$baz say((foo<$bar+1>), $baz);
- say foo.<$bar+1>,$baz say((foo<$bar+1>), $baz);
+ say foo<$bar+1>,$baz illegal, need foo()<>
+ say foo.<$bar+1>,$baz illegal, need foo().<>
say foo <$bar+1>,$baz say(foo(<$bar+1>, $baz));
say foo .<$bar+1>,$baz say(foo($_.<$bar+1>, $baz));
@@ -263,10 +268,10 @@
term vs postfix vs infix, and will interpret an overloaded character
like C<< < >> accordingly:
- any <a b c> any('a','b','c') # term
- any<a b c> (any).{'a','b','c'} # postfix
- any()<a b c> (any).{'a','b','c'} # postfix
- any() < $x (any) < $x # infix
+ any <a b c> any('a','b','c') # term
+ any()<a b c> (any).{'a','b','c'} # postfix
+ any() < $x (any) < $x # infix
+ any<a b c> [syntax error] # illegal postfix
This will seem unfamiliar and "undwimmy" to Perl 5 programmers, who
are used to a grammar that sloppily hardwires a few postfix operators
@@ -278,6 +283,18 @@
that is not followed by a comma or colon. (And a semicolon is implied if
the closure is the final thing on a line.)
+=item * A function predeclared as 0-ary is never considered list
+operator, though it allows an optional set of empty parentheses.
+Unlike functions and list operators with arguments (see above),
+a 0-ary function does not require parentheses even if followed
+immediately by a postfix.
+
+=item * A non-multi sub predeclared with an arity of exactly 1 parses
+as a named unary in precedence. All other subs with arguments
+parse as list operators. (In other words, a named unary operator
+may be declared to take extra arguments only if they are named-only
+arguments.)
+
=back
=head1 New operators
Smylers
> New Revision: 10077
> Modified: doc/trunk/design/syn/S02.pod
> ==============================================================================
>
> - foo.bar # foo().bar -- postfix prevents args
> + foo.bar # foo().bar -- illegal postfix, must use foo().bar
> foo .bar # foo($_.bar) -- no postfix starts with whitespace
I don't think it makes much sense to start the comments with an
alternate form for the expressions now denoted as illegal -- "here's
some other syntax which this used to be the same as but it no longer is"
probably only confuses the casual reader.
Smylers
Aaron Sherman
On a side note, does that apply only to expressions that start with an
identifier, or does that mean that:
$socket.accept.getlines
will have to be:
$socket.accept().getlines
?
Larry Wall
No, this is only list operators, not methods. So
$socket.accept.getlines
is fine, but
foo.accept.getlines
is not, unless foo is predeclared 0-ary.
But I am tempted to extend it to keywords like "else" and "sub" as
well, because any foo{} confusion is going to train people not to
think about ...{} as a subscript when they should think about it
whenever there's a lack of whitespace. It would be nice if :foo{}
were the only exception to that.
For similar reasons, I'm also tempted to say that if() is always a
function call, because it looks like one.
Larry