Author: autrijus
Date: Wed Apr 5 19:18:40 2006
New Revision: 8570
Modified:
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
doc/trunk/design/syn/S10.pod
doc/trunk/design/syn/S12.pod
Log:
* S04/S06/S09/S10/S12: Excise "reference" from them.
Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Apr 5 19:18:40 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 1 Apr 2006
+ Last Modified: 6 Apr 2006
Number: 4
- Version: 12
+ Version: 13
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -400,8 +400,8 @@
A C<return> always exits from the lexically surrounding sub
or method definition (that is, from a function officially declared
with the C<sub>, C<method>, or C<submethod> keywords). Pointy subs
-and bare closures are transparent to C<return>. If you pass a reference
-to a closure outside of its official "sub" scope, it is illegal to
+and bare closures are transparent to C<return>. If you pass a closure
+object outside of its official "sub" scope, it is illegal to
return from it. You may only leave the closure block itself with C<leave>
or by falling off the end of it.
@@ -828,9 +828,9 @@
so that if you ever use the current reference to the routine, it gets
the current snapshot of its world, lexically speaking.
-Some closures produce references at compile time that cannot be
+Some closures produce C<Code> objects at compile time that cannot be
cloned, because they're not attached to any runtime code that can
-actively clone them. C<BEGIN>, C<CHECK>, C<INIT>, and C<END> blocks probably
+actively clone them. C<BEGIN>, C<CHECK>, C<INIT>, and C<END> blocks
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
Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod (original)
+++ doc/trunk/design/syn/S06.pod Wed Apr 5 19:18:40 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 21 Mar 2003
- Last Modified: 1 Apr 2006
+ Last Modified: 6 Apr 2006
Number: 6
- Version: 22
+ Version: 23
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -119,11 +119,11 @@
Raw blocks are also executable code structures in Perl 6.
-Every block defines an object of type C<Code>, which may either be executed
-immediately or passed on as a C<Code> reference argument. A
+Every block defines an object of type C<Code>, which may either be
+executed immediately or passed on as a C<Code> object. A
bare block where an operator is expected is bound to the current
statement level control syntax. A bare block where a term is expected
-merely produces a reference. If the term bare block occurs in a list,
+merely produces a C<Code> object. If the term bare block occurs in a list,
it is considered the final element of that list unless followed immediately
by a comma or comma surrogate.
@@ -399,7 +399,7 @@
doit %hash{'b'}:p,1,2,3;
instead.. (The C<:p> stands for "pairs", not "positional"--the
-C<:p> adverb may be placed on any hash reference to make it mean
+C<:p> adverb may be placed on any Hash objects to make it mean
"pairs" instead of "values".)
Pair constructors are recognized syntactically at the call level and
@@ -1821,7 +1821,7 @@
} # Old values of $*foo and &bar reinstated at this point
C<temp> invokes its argument's C<.TEMP> method. The method is expected
-to return a reference to a subroutine that can later restore the current
+to return a C<Code> object that can later restore the current
value of the object. At the end of the lexical scope in which the
C<temp> was applied, the subroutine returned by the C<.TEMP> method is
executed.
@@ -1979,7 +1979,7 @@
&textfrom := &substr.assuming:str($text):len(Inf);
-It returns a reference to a subroutine that implements the same behaviour
+It returns a C<Code> object that implements the same behaviour
as the original subroutine, but has the values passed to C<.assuming>
already bound to the corresponding parameters:
@@ -2150,7 +2150,7 @@
C<{...}> is always a block. However, if it is completely empty or
consists of a single list, the first element of which is either a hash
-or a pair, it is executed immediately to compose a hash reference.
+or a pair, it is executed immediately to compose a Hash object.
The standard C<pair> list operator is equivalent to:
Modified: doc/trunk/design/syn/S09.pod
==============================================================================
--- doc/trunk/design/syn/S09.pod (original)
+++ doc/trunk/design/syn/S09.pod Wed Apr 5 19:18:40 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 13 Sep 2004
- Last Modified: 1 Apr 2006
+ Last Modified: 6 Apr 2006
Number: 9
- Version: 6
+ Version: 7
=head1 Overview
@@ -263,7 +263,7 @@
Arrays by default are one dimensional, but may be declared to have any
dimensionality supported by the implementation. You may use arrays
-just like scalar references--the main caveat is that you have to use
+just like scalars -- the main caveat is that you have to use
binding rather than assignment to set one without copying:
@b := @a[0...:by(2)]
@@ -550,7 +550,7 @@
autothreading on that parameter. Only individually declared parameters
may autothread. (Note that positional array and hash parameters are
in fact scalar parameters, though, so you could pass a junction of
-array or hash references.)
+array or hash objects.)
=head1 Parallelized parameters and autothreading
@@ -676,12 +676,13 @@
=head1 Autovivification
Autovivification will only happen if the vivifiable path is used as a
-container, by binding, assigning, or taking a reference. On the other hand,
-value extraction does not autovivify.
+container, by binding, assigning, or capturing into an argument list.
+On the other hand, value extraction does not autovivify.
This is as opposed to Perl 5, where autovivification could happen
unintentionally, even when the code looks like a non-destructive test:
+ # This is Perl 5 code
my %hash;
exists $hash{foo}{bar}; # creates $hash{foo} as an empty hash reference
Modified: doc/trunk/design/syn/S10.pod
==============================================================================
--- doc/trunk/design/syn/S10.pod (original)
+++ doc/trunk/design/syn/S10.pod Wed Apr 5 19:18:40 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 28 Mar 2006
+ Last Modified: 6 Apr 2006
Number: 10
- Version: 5
+ Version: 6
=head1 Overview
@@ -112,15 +112,15 @@
Such a name does not include its container name, unlike Perl 5's magical
C<$AUTOLOAD> variable.
-The C<CANDO> is expected to return a reference to an inner
-container object of the proper sort (i.e. a variable, subroutine,
-or method reference), or to a proxy object that can "autovivify"
-lazily, or undef if that name is not to be considered declared in the
-namespace in question. The declaration merely defines the interface
-to the new object. That object need not be completely defined yet,
-though the C<CANDO> routine is certainly I<allowed> to define it
-eagerly, and even install the inner object into the outer container
-(the symbol table) if it wants to cache the declaration.
+The C<CANDO> is expected to return an inner container object of the proper
+sort (i.e. a variable, subroutine, or method object), or to a proxy
+object that can "autovivify" lazily, or C<undef> if that name is not to be
+considered declared in the namespace in question.
+
+The declaration merely defines the interface to the new object. That object
+need not be completely defined yet, though the C<CANDO> routine is certainly
+I<allowed> to define it eagerly, and even install the inner object into the
+outer container (the symbol table) if it wants to cache the declaration.
At declaration time it might not yet be known whether the inner
container object will be used in lvalue or rvalue context; the use
Modified: doc/trunk/design/syn/S12.pod
==============================================================================
--- doc/trunk/design/syn/S12.pod (original)
+++ doc/trunk/design/syn/S12.pod Wed Apr 5 19:18:40 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 1 Apr 2006
+ Last Modified: 6 Apr 2006
Number: 12
- Version: 12
+ Version: 13
=head1 Overview
@@ -279,19 +279,21 @@
Setter methods that expect the new value as an argument do not fall
into the well-behaved category, however.)
-Method calls on scalars go to the referenced object (autoboxing value
-types as necessary):
+Method calls on mutable scalars always go to the object contained in
+the scalar (autoboxing value types as necessary):
$result = $object.doit();
$length = "mystring".codes;
-But method calls on containers go to the container:
+Method calls on non-scalar variables just calls the C<Array>, C<Hash>
+or C<Code> object bound to the variable:
$elems = @array.elems;
@keys = %hash.keys;
$sig = &sub.signature;
-Use the C<variable> pseudo-function to get at the container of a scalar
variable.
+Use the C<variable> pseudo-function on a scalar variable to get at its
+underlying C<Scalar> object:
if variable($scalar).constant {...}
@@ -1117,8 +1119,8 @@
has $.fur handles (s/^furget_/get_/);
-Ordinarily delegation is based on an attribute holding an object
-reference, but it can also be based on the return value of a method:
+Ordinarily delegation is based on an attribute holding an object, but it can
+also be based on the return value of a method:
method select_tail handles <wag hang> {...}
@@ -1504,7 +1506,7 @@
which is true if C<$obj> either "does" or "isa" C<Dog> (or "isa"
something that "does" C<Dog>).
-Unlike in Perl 5 where C<.can> returns a single routine reference,
+Unlike in Perl 5 where C<.can> returns a single C<Code> object,
Perl 6's version of C<.meta.can> returns a "WALK" iterator for a
set of routines that match the name, including all autoloaded and
wildcarded possibilities. In particular, C<.can> interrogates
