[svn:perl6-synopsis] r8698 - doc/trunk/design/syn
Author: autrijus
Date: Sat Apr 15 06:17:49 2006
New Revision: 8698
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
Log:
* Synopses: Change "Arguments" to "Capture" to avoid using a
plural word as a class name. (Also it makes it easier later
to say that "Match" is a subclass of "Capture".)
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podSat Apr 15 06:17:49 2006
@@ -525,35 +525,33 @@
=item *
-An argument list object (C) may be created with backslashed parens:
+An argument list object (C) may be created with backslashed parens:
$args = \(1,2,3,:mice)
-Values in C values are parsed as ordinary expressions, marked as
-positional, named, to-be-flattened, and so on.
+Values in C are parsed as ordinary expressions, marked as invocant,
+positional, named, and so on.
-Like C objects, C are immutable in the abstract, but
-evaluates its arguments lazily. Before everything inside a C are
+Like C objects, C objects are immutable in the abstract, but
+evaluates its arguments lazily. Before everything inside a C are
fully evaluated (which happens at compile time when all the arguments are
constants), the eventual value may well be unknown. All we know is that is
that we have the promise to make the bits of it immutable as they become known.
-C objects may contain multiple unresolved iterators such as pipes
+C objects may contain multiple unresolved iterators such as pipes
or slices. How these are resolved depends on what they are eventually
bound to. Some bindings are sensitive to multiple dimensions while
others are not.
-You may cast C to other types with a prefix sigil operator:
+You may retrieve parts from a C object with a prefix sigil operator:
$args = \3; # same as "$args = \(3)"
$$args; # same as "$args as Scalar" or "Scalar($args)"
@$args; # same as '$args as Array" or "Array($args)"
%$args; # same as '$args as Hash" or "Hash($args)"
-&$args; # same as '$args as Code" or "Code($args)"
When cast into an array, you can access all the positional arguments; into a
-hash, all named arguments; into a scalar, the invocant; into code, its slurpy
-nameless block.
+hash, all named arguments; into a scalar, its invocant.
All prefix sigil operators accept one positional argument, evaluated in
scalar context as a rvalue. They can interpolate in strings if called with
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Apr 15 06:17:49 2006
@@ -61,7 +61,7 @@
=item * The backslash operator captures its arguments, and returns an
object representing those arguments. You can I this object
in several ways to retrieve different parts of the arguments; see the
-definition of C S02 for details.
+definition of C in S02 for details.
=item * The old scalar C<..> flipflop operator is now done with
C operator. (C<..> now always produces a Range object
@@ -456,7 +456,7 @@
as is this:
-my $args = \(@foo, @bar);# construct Arguments object
+my $args = \(@foo, @bar);# construct a Capture object
push *$args;
In list context, a Scalar holding an Array object does not flatten. Hence
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podSat Apr 15 06:17:49 2006
@@ -403,7 +403,7 @@
"pairs" instead of "values".)
Pair constructors are recognized syntactically at the call level and
-put into the named slot of the C structure. Hence they may be
+put into the named slot of the C structure. Hence they may be
bound to positionals only by name, not as ordinary positional C
objects. Leftover named arguments can be slurped into a slurpy hash.
@@ -579,7 +579,7 @@
so that you can use more descriptive internal parameter names without
imposing inconveniently long external labels on named arguments.
-Arguments that correspond to named parameters are evaluated in scalar
+Capture that correspond to named parameters are evaluated in scalar
context. They can only be passed by name, so it doesn't matter what
order you pass them in, so long as they don't intermingle with any
positional arguments:
@@ -681,13 +681,13 @@
=head2 Argument list binding
-The underlying C object may be bound to a single scalar
+The underlying C object may be bound to a single scalar
parameter marked with a C<\>.
sub bar ($a,$b,$c,:$mice) { say $mice }
sub foo (\$args) { say $args.perl; &bar.call($args); }
-The C<.call> method of C objects accepts a
Capturing the Captures.
As promised yesterday, today gaal and I entered a gobby Q/A session, producing the first document under the Perl6::FAQ tree, on the newly coined Capture objects (previously known as Arguments) objects: http://svn.openfoundry.org/pugs/docs/Perl6/FAQ/Capture.pod A HTMLized version is also available online: http://pugs.blogs.com/pugs/2006/04/perl6faqcapture.html With gaal's clearly-worded, carefully probing questions, I found myself discovering unforeseen consequences of the new design -- e.g. @y := (1,2,3) is actually an error, and one would need to say [EMAIL PROTECTED] := (1,2,3) instead. Fortunately, the design seems to stand against the scrutiny. So after TimToady reported consent from @Larry on the s:g/Arguments/Capture/ name change, I committed that to the Synopses. As this represents a rather drastic departure from Perl 5's model, I'd very much welcome reviews, comments, as well as more questions -- please feel free to commit directly to the FAQ file, and we'll pick up from there. :-) signature.asc Description: OpenPGP digital signature
[svn:perl6-synopsis] r8699 - doc/trunk/design/syn
Author: larry
Date: Sat Apr 15 11:25:52 2006
New Revision: 8699
Modified:
doc/trunk/design/syn/S04.pod
Log:
Updated statement-level block syntax to favor statement block over arg block.
(Must use old-fashioned parens around conditional or args otherwise.)
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podSat Apr 15 11:25:52 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 10 Apr 2006
+ Last Modified: 15 Apr 2006
Number: 4
- Version: 14
+ Version: 15
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -60,10 +60,27 @@
my $x = $x;
will no longer see the value of the outer C<$x>; you'll need to say
+either
my $x = $OUTER::x;
-instead. (It's illegal to declare C<$x> twice in the same scope.)
+or
+
+my $x = OUTER::<$x>;
+
+instead.
+
+If you declare a lexical twice in the same scope, it is the same lexical:
+
+my $x;
+my $x;
+
+If you've referred to C<$x> prior to the first declaration, and the compiler
+tentatively bound it to C<$OUTER::x>, then it's an error to declare it, and
+the compiler is allowed to complain at that point. If such use can't
+be detected because it is hidden in an eval, then it is erroneous, since
+the C compiler might bind to either C<$OUTER::x> or the subsequently
+declared "C".
As in Perl 5, "C" introduces a lexically scoped alias for
a variable in the current package.
@@ -143,10 +160,8 @@
...
}
-Conditional statement modifiers also work as in Perl 5. So do the
-implicit conditionals implied by short-circuit operators. And there's
-a new C in Perl 6--except that you have to spell it C.
-C<:-)>
+Conditional statement modifiers work as in Perl 5. So do the
+implicit conditionals implied by short-circuit operators.
=head1 Loop statements
@@ -289,7 +304,10 @@
Although a bare block is no longer a do-once loop, it still executes
immediately as in Perl 5. If you wish to return a closure from a
-function, you must use an explicit C.
+function, you must use an explicit prefix such as C or C
+or C<< -> >>. (Use of a placeholder parameter is deemed insufficiently
+explicit because it's not out front where it can be seen. You can, of
+course, use a placeholder parameter if you also use C.)
=head1 Switch statements
@@ -592,8 +610,8 @@
parentheses aren't necessary around C because the whitespace
between C and the block forces the block to be considered a
block rather than a subscript. This works for all control structures,
-not just the new ones in Perl 6. A bare block where an operator
-is expected is always considered a statement block if there's space
+not just the new ones in Perl 6. A top-level bare block
+is always considered a statement block if there's space
before it:
if $foo { ... }
@@ -602,11 +620,31 @@
while $more { ... }
for 1..10 { ... }
-(You can still parenthesize the expression argument for old times' sake,
-as long as there's a space between the closing paren and the opening
-brace.)
+You can still parenthesize the expression argument for old times'
+sake, as long as there's a space between the closing paren and the
+opening brace. You I parenthesize the expression if there is
+a bare block that would be misinterpreted as the statement's block.
+This is regardless of whether a term or operator is expected where
+the bare block occurs. (A block inside brackets, or used as as
+postcircumfix is fine, though.) Any block with whitespace
+in front of it will be taken as terminating the conditional, even if
+the conditional expression could take another argument. Therefore
+
+if -e { say "exists" } { extra() }
+
+is always parsed as
+
+if (-e) { say "exists" }; { extra() }
+
+rather than
+
+if (-e { say "exists" }) { extra() }
+
+Apart from that, it is illegal to use a bare closure where an
+operator is expected. (Remove the whitespace if you wish it to be
+a postcircumfix.)
-On the other hand, anywhere a term is expected, a block is taken to
+Anywhere a term is expected, a block is taken to
be a closure definition (an anonymous subroutine). If the closure
appears to delimit nothing but a comma-separated list starting with
a pair (counting a single pair as a list of one element), the closure
@@ -627,29 +665,32 @@
$hashref = hash("a", 1);
If a closure is the right argument of the dot operator, the closure
-is interpreted as a hash subscript, even if there is space before the dot.
+is interpreted as a hash subscript.
$ref = {$x}; # closure because term expected
-if $term{$x} # subscript because operator expected
+if $term{$x} # subscript because postfix expected
if $term {$x} # expression followed by statement block
-if $term .{$x} # valid s
Re: [svn:perl6-synopsis] r8698 - doc/trunk/design/syn
Some grammar nits I'd like to pick... Alarmingly, the Capture semantics are starting to make perfect sense to me now.. On Apr 15, 2006, at 16:17, [EMAIL PROTECTED] wrote: Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 15 06:17:49 2006 +Like C objects, C objects are immutable in the abstract, but +evaluates its arguments lazily. Before everything inside a C are fully evaluated (which happens at compile time when all the arguments are constants), the eventual value may well be unknown. All we know is that is that we have the promise to make the bits of it immutable as they become known. Tense disagreements: "capture objects ... evaluates its arguments" "Before everything ... are fully evaluated" "is that" repeated twice Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSat Apr 15 06:17:49 2006 -Arguments that correspond to named parameters are evaluated in scalar +Capture that correspond to named parameters are evaluated in scalar context. They can only be passed by name, so it doesn't matter what I think that was "arguments" the word, not C the object.
[svn:perl6-synopsis] r8700 - doc/trunk/design/syn
Author: larry Date: Sat Apr 15 18:38:36 2006 New Revision: 8700 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S06.pod Log: Cleanup typos. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSat Apr 15 18:38:36 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 10 Apr 2006 + Last Modified: 15 Apr 2006 Number: 2 - Version: 22 + Version: 23 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -533,9 +533,9 @@ positional, named, and so on. Like C objects, C objects are immutable in the abstract, but -evaluates its arguments lazily. Before everything inside a C are +evaluate their arguments lazily. Before everything inside a C is fully evaluated (which happens at compile time when all the arguments are -constants), the eventual value may well be unknown. All we know is that is +constants), the eventual value may well be unknown. All we know is that we have the promise to make the bits of it immutable as they become known. C objects may contain multiple unresolved iterators such as pipes Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSat Apr 15 18:38:36 2006 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 6 Apr 2006 + Last Modified: 15 Apr 2006 Number: 6 - Version: 23 + Version: 24 This document summarizes Apocalypse 6, which covers subroutines and the @@ -579,7 +579,7 @@ so that you can use more descriptive internal parameter names without imposing inconveniently long external labels on named arguments. -Capture that correspond to named parameters are evaluated in scalar +Arguments that correspond to named parameters are evaluated in scalar context. They can only be passed by name, so it doesn't matter what order you pass them in, so long as they don't intermingle with any positional arguments:
