Author: larry
Date: Sat Feb 25 00:29:54 2006
New Revision: 7863
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S05.pod
Log:
Various tweaks and comments from TheDamian.
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Sat Feb 25 00:29:54 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 16 Feb 2006
+ Last Modified: 25 Feb 2006
Number: 2
- Version: 16
+ Version: 17
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -111,7 +111,7 @@
=item *
In support of OO encapsulation, there is a new fundamental datatype:
-B<opaque>. External access to opaque objects is always through method
+B<P6opaque>. External access to opaque objects is always through method
calls, even for attributes.
=item *
@@ -211,9 +211,11 @@
=item *
-Perl 6 intrinsically supports big integers and rationals through
-its system of type declarations. C<Int> automatically supports
-promotion to arbitrary precision. C<Rat> supports arbitrary precision
+Perl 6 intrinsically supports big integers and rationals through its
+system of type declarations. C<Int> automatically supports promotion
+to arbitrary precision. (C<Num> may support arbitrary-precision
+floating-point arithmatic, but is not required to unless we can do
+so portably and efficiently.) C<Rat> supports arbitrary precision
rational arithmetic. Value types like C<int> and C<num> imply
the natural machine representation for integers and floating-point
numbers, respectively, and do not promote to arbitrary precision.
Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Sat Feb 25 00:29:54 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 1 Feb 2006
+ Last Modified: 25 Feb 2006
Number: 3
- Version: 12
+ Version: 13
=head1 Operator renaming
@@ -107,10 +107,10 @@
of semantics. Anywhere you used C<=~> before you now use C<~~>, but C<~~> is
much more general now. See L<Synopsis 4> for details. (To catch "brainos",
the Perl 6 parser defines an C<< infix:<=~> >> macro which always fails at
-compile time with a message directing the user either to use C<~~> instead,
+compile time with a message directing the user either to use C<~~> or C<~=>
instead,
or to put a space between if they really wanted to assign a stringified value.)
-=item * Unary C<.> calls its single argument (which must be a method, or an
+=item * Unary C<.> calls its single argument (which must be a method, or a
dereferencer for a hash or array) on C<$_>.
=item * The C<..> range operator has variants with C<^> on either
@@ -118,10 +118,18 @@
produces a Range object. Range objects are lazy iterators, and can
be interrogated for their current C<.min> and C<.max> values (which
change as they are iterated). Ranges are not autoreversing: C<2..1>
-is always a null range, as is C<1^..^2>. However, smart matching
-against a Range object smartmatches the endpoints in the domain of
-the object being matched, so C<< 1.5 ~~ 1^..^2 >> is true.
-(But C<< 2.1 ~~ 1..2 >> is false.)
+is always a null range, as is C<1^..^2>. To reverse a range use:
+
+ 2..1:by(-1)
+ reverse 1..2
+
+(The C<reverse> is preferred because it works for alphabetic ranges
+as well.)
+
+Because C<Range> objects are lazy, they do not automatically generate
+a list. So smart matching against a Range object smartmatches the
+endpoints in the domain of the object being matched, so C<< 1.5 ~~
+1^..^2 >> is true. (But C<< 2.1 ~~ 1..2 >> is false.)
=item * The unary C<^> operator generates a range from C<0> up to
one less than its argument. so C<^4> is short for C<0..^4> or C<0..3>.
@@ -133,7 +141,7 @@
=item * However, C<...> as a term is the "yada, yada, yada" operator,
which is used as the body in function prototypes. It complains
-bitterly if it is ever executed. Actually, it calls C<fail>. Variant
+bitterly (by calling C<fail>) if it is ever executed. Variant
C<???> calls C<warn>, and C<!!!> calls C<die>.
=item * In addition, to the ordinary C<.> method invocation, there are
@@ -432,7 +440,7 @@
=head1 Precedence
-Perl 6 has 22 precedence levels (fewer than Perl 5):
+Perl 6 has 22 precedence levels (which is fewer than Perl 5):
terms 42 "eek" $x /abc/ (1+2) a(1) :by(2) .meth listop
method postfix . .+ .? .* .() .[] .{} .«» .=
Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Sat Feb 25 00:29:54 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 24 Feb 2006
+ Last Modified: 25 Feb 2006
Number: 4
- Version: 9
+ Version: 10
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -41,9 +41,9 @@
A bare closure without placeholder arguments that uses C<$_>
(either explicitly or implicitly) is treated as though C<$_> were a
-placeholder argument:
+a formal parameter:
- $func = { print if $_ };
+ $func = { print if $_ }; # Same as: $func = -> $_ { print if $_ };
$func("printme");
In any case, all formal parameters are the equivalent of C<my> variables
@@ -208,11 +208,11 @@
for zip(@a;@b) -> [$a, $b] { print "[$a, $b]\n" }
The list is evaluated lazily by default, so instead of using a C<while>
-to read a file a line at a time:
+to read a file a line at a time as you would in Perl 5:
while my $line = <$*IN> {...}
-you should use a C<for> instead:
+in Perl 6 you should use a C<for> instead:
for =$*IN -> $line {...}
@@ -459,7 +459,7 @@
information about the error. If you try to use an undefined value,
that information can then be conveyed to the user. In essence, undef
can be an unthrown exception object that just happens to return 0 when
-you ask it whether it's defined or it's true. Since $! contains the
+you ask it whether it's defined or it's true. Since C<$!> contains the
current error code, saying C<die $!> will turn an unthrown exception
into a thrown exception. (A bare C<die> does the same.)
@@ -477,7 +477,8 @@
printout for the new exception should include the old exception
information so that the user can trace back to the original error.
(Likewise, rethrown exceptions add information about how the exception
-is propagated.)
+is propagated.) The exception stack within C<$!> is available as
+C<$![]>.
Exception objects are born "unhandled". The C<$!> object keeps track of
whether it's currently "handled" or "unhandled". The exception in C<$!> still
@@ -513,6 +514,10 @@
my $compiletime = BEGIN { localtime };
our $temphandle = FIRST { maketemp() };
+Code that is generated at run time can still fire off C<CHECK>
+and C<INIT> blocks, though of course those blocks can't do things that
+would require travel back in time.
+
Some of these also have corresponding traits that can be set on variables.
These have the advantage of passing the variable in question into
the closure as its topic:
@@ -522,7 +527,7 @@
Apart from C<CATCH> and C<CONTROL>, which can only occur once, most of
these can occur multiple times within the block. So they aren't really
-traits, exactly--they actually add themselves onto a list stored in the
+traits, exactly--they add themselves onto a list stored in the
actual trait. So if you examine the C<ENTER> trait of a block, you'll
find that it's really a list of closures rather than a single closure.
@@ -650,10 +655,6 @@
macro statement_control:<while> ($expr, &whileblock) {...}
macro statement_control:<BEGIN> (&beginblock) {...}
-It's possible the full name of the C<if> operator is now:
-
- statement_control:<if elsif else>
-
Statement-level constructs may start only where the parser is expecting
the start of a statement. To embed a statement in an expression you
must use something like C<do {...}> or C<try {...}>.
@@ -823,7 +824,7 @@
Some closures produce references at compile time that cannot be
cloned, because they're not attached to any runtime code that can
-actively clone them. BEGIN, CHECK, INIT, and END blocks probably
+actively clone them. C<BEGIN>, C<CHECK>, C<INIT>, and C<END> blocks probably
fall into this category. Therefore you can't reliably refer to
run-time variables from them even if they appear to be in scope.
(The compile-time closure may, in fact, see a some kind of permanent
@@ -832,7 +833,7 @@
only safe to refer to package variables and file-scoped lexicals from
such a routine.
-On the other hand, it is required that CATCH and LEAVE blocks be able
+On the other hand, it is required that C<CATCH> and C<LEAVE> blocks be able
to see transient variables in their current lexical scope, so their
cloning status depends at least on the cloning status of the block
they're in.
Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Sat Feb 25 00:29:54 2006
@@ -15,7 +15,7 @@
Date: 24 Jun 2002
Last Modified: 25 Feb 2006
Number: 5
- Version: 11
+ Version: 12
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them "rules" because they haven't been
@@ -346,7 +346,7 @@
=item *
-C<#> now always introduces a comment.
+An unescaped C<#> now always introduces a comment.
=item *
@@ -464,7 +464,7 @@
=item *
The default way in which the engine handles a scalar is to match it
-as a C<< <'...'> >> literal (i.e.it does not treat the interpolated string
+as a C<< <'...'> >> literal (i.e. it does not treat the interpolated string
as a subpattern). In other words, a Perl 6:
/ $var /
@@ -486,7 +486,7 @@
/ [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /
-As with a scalar variable, each one is matched as a literal.
+As with a scalar variable, each element is matched as a literal.
=item *
@@ -1590,9 +1590,9 @@
=item *
-If a subrule appears two (or more) times in the same lexical scope
-(i.e. twice within the same subpattern and alternation), or if the
-subrule is quantified anywhere within the entire rule, then its
+If a subrule appears two (or more) times in any branch of a lexical
+scope (i.e. twice within the same subpattern and alternation), or if the
+subrule is quantified anywhere within a given scope, then its
corresponding hash entry is always assigned a reference to an array of
C<Match> objects, rather than a single C<Match> object.
@@ -1689,12 +1689,12 @@
then the outer capturing parens no longer capture into the array of
C<$/> (like unaliased parens would). Instead the aliased parens capture
into the hash of C<$/>; specifically into the hash element
-whose key is alias name.
+whose key is the alias name.
=item *
So, in the above example, a successful match sets
-C<< $<key> >> (i.e. C<< $/<key> >>), but I<not> C<$0> (i.e. C<< $/[0] >>).
+C<< $<key> >> (i.e. C<< $/<key> >>), but I<not> C<$0> (i.e. not C<< $/[0] >>).
=item *
@@ -1900,7 +1900,7 @@
list of C<Match> objects (as described in L<Quantified subpattern
captures> and L<Repeated captures of the same subrule>).
So the corresponding array element or hash entry for the alias will
-contain a referece to an array, instead of a single C<Match> object.
+contain a reference to an array, instead of a single C<Match> object.
=item *
@@ -2321,20 +2321,20 @@
grammar Letter {
rule text { <greet> <body> <close> }
- rule greet :w { [Hi|Hey|Yo] $to:=(\S+?) , $$}
+ rule greet :w { [Hi|Hey|Yo] $<to>:=(\S+?) , $$}
rule body { <line>+ }
- rule close :w { Later dude, $from:=(.+) }
+ rule close :w { Later dude, $<from>:=(.+) }
# etc.
}
grammar FormalLetter is Letter {
- rule greet :w { Dear $to:=(\S+?) , $$}
+ rule greet :w { Dear $<to>:=(\S+?) , $$}
- rule close :w { Yours sincerely, $from:=(.+) }
+ rule close :w { Yours sincerely, $<from>:=(.+) }
}
@@ -2469,7 +2469,7 @@
are strings, they are concatenated virtually into a single logical
string. If the array elements are tokens or other such objects, the
objects must provide appropriate methods for the kinds of rules to
-match against. It is an assertion error to match a string matching
+match against. It is an assertion error to match a string-matching
assertion against an object that doesn't provide a string view.
However, pure token objects can be parsed as long as the match rule
restricts itself to assertions like:
@@ -2486,4 +2486,3 @@
@array».match($rule)
=back
-
