Author: autrijus
Date: Fri Feb 24 05:49:02 2006
New Revision: 7839
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
Log:
* Textual cleanup of S2/4/6. No functional changes.
- Change sentences like "Perl 6 will support" to "Perl 6 supports"
- References to A* becomes S0*.
- Make it clear that "::Foo.bar()" does not interpolate in strings.
- The ".each" in S06 was actually a thinko for ".map".
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Fri Feb 24 05:49:02 2006
@@ -111,22 +111,23 @@ be trivial to declare them as a macro).
=item *
In support of OO encapsulation, there is a new fundamental datatype:
-"opaque". External access to opaque objects is always through method
+B<opaque>. External access to opaque objects is always through method
calls, even for attributes.
=item *
-Perl 6 will have an optional type system that helps you write safer
+Perl 6 has an optional type system that helps you write safer
code that performs better. The compiler is free to infer what type
information it can from the types you supply, but will not complain
about missing type information unless you ask it to.
=item *
-Perl 6 will support the notion of "properties" on various kinds of
+Perl 6 supports the notion of B<properties> on various kinds of
objects. Properties are like object attributes, except that they're
managed by the individual object rather than by the object's class.
-According to A12, properties are actually implemented by a
+
+According to S12, properties are actually implemented by a
kind of mixin mechanism, and such mixins are accomplished by the
generation of an individual anonymous class for the object (unless
an identical anonymous class already exists and can safely be shared).
@@ -134,7 +135,7 @@ an identical anonymous class already exi
=item *
Properties applied to compile-time objects such as variables and
-classes are also called "traits". Traits are not expected to change
+classes are also called B<traits>. Traits are not expected to change
at run time. Changing run-time properties should be done via mixin
instead, so that the compiler can optimize based on declared traits.
@@ -150,7 +151,7 @@ than in Perl 5.
A variable's type is an interface contract indicating what sorts
of values the variable may contain. More precisely, it's a promise
that the object or objects contained in the variable are capable of
-responding to the methods of the indicated "role". See A12 for more
+responding to the methods of the indicated "role". See S12 for more
about roles. A variable object may itself be bound to a container
type that specifies how the container works without necessarily
specifying what kinds of things it contains.
@@ -158,15 +159,16 @@ specifying what kinds of things it conta
=item *
You'll be able to ask for the length of an array, but it won't be
-called that, because "length" does not specify units. So
-C<.elems> is the number of array elements. (You can also
+called that, because C<length> does not specify units. So
+C<.elems> is the number of array elements. You can also
ask for the length of an array in bytes or codepoints or graphemes.
-Same for strings. There is no C<.length> on strings either.)
+The same methods apply to strings as well: there is no C<.length> on
+strings either.
=item *
C<my Dog $spot> by itself does not automatically call a C<Dog> constructor.
-The actual constructor syntax turns out to be C<my Dog $spot.=new;>,
+The actual constructor syntax turns out to be C<my Dog $spot .= new;>,
making use of the C<.=> mutator method-call syntax.
=item *
@@ -194,7 +196,7 @@ than the native type can speed it up.)
=item *
-All Object types support the "undefined" role, and may contain an
+All Object types support the C<undefined> role, and may contain an
alternate set of attributes when undefined, such as the unthrown
exception explaining why the value is undefined. Non-object types
are not required to support undefinedness, but it is an error to
@@ -209,7 +211,7 @@ used as a "kind" when the context requir
=item *
-Perl 6 will intrinsically support big integers and rationals through
+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
rational arithmetic. Value types like C<int> and C<num> imply
@@ -227,10 +229,10 @@ on overflow.
=item *
-A C<Str> is a Unicode string object of some sort. A C<str> is
-a stringish view of an array of integers, and has no Unicode or
-character properties without explicit conversion to some kind of C<Str>.
-Typically it's an array of bytes serving as a buffer.
+A C<Str> is a Unicode string object. A C<str> is a stringish view of
+an array of integers, and has no Unicode or character properties without
+explicit conversion to some kind of C<Str>. Typically it's an array of bytes
+serving as a buffer.
=back
@@ -242,7 +244,7 @@ The C<$pkg'var> syntax is dead. Use C<$
=item *
-Perl 6 includes a system of "sigils" to mark the fundamental
+Perl 6 includes a system of B<sigils> to mark the fundamental
structural type of a variable:
$ scalar
@@ -275,7 +277,7 @@ and its following name or construct.
Ordinary sigils indicate normally scoped variables, either lexical
or package scoped. Oddly scoped variables include a secondary sigil
-(a "twigil") that indicates what kind of strange scoping the variable
+(a B<twigil>) that indicates what kind of strange scoping the variable
is subject to:
$foo ordinary scoping
@@ -330,7 +332,7 @@ formats for both key and value in the fi
Subscripts now consistently dereference the reference produced by
whatever was to their left. Whitespace is not allowed between a
variable name and its subscript. However, there is a corresponding
-"dot" form of each subscript (C<@foo.[1]> and C<%bar.{'a'}>) which
+B<dot> form of each subscript (C<@foo.[1]> and C<%bar.{'a'}>) which
allows optional whitespace before the dot (except when interpolating).
Constant string subscripts may be placed in angles, so C<%bar.{'a'}>
may also be written as C<< %bar<a> >> or C<< %bar.<a> >>.
@@ -353,8 +355,9 @@ context specifiers such as + for numbers
There is a need to distinguish list assignment from list binding.
List assignment works exactly as it does in Perl 5, copying the
values. There's a new C<:=> binding operator that lets you bind
-names to array and hash references without copying, just as function
-arguments are bound to formal parameters. See A6.
+names to array and hash references without copying, just as subroutine
+arguments are bound to formal parameters. See S06 for more about
+parameter binding.
=item *
@@ -404,8 +407,8 @@ insert optional whitespace before the do
=item *
-With multis, C<&foo> may not be sufficient to uniquely name a specific
-function. In that case, the type may be refined by using a
+With multiple dispatch, C<&foo> may not be sufficient to uniquely name a
+specific function. In that case, the type may be refined by using a
signature literal as a postfix operator:
&foo:(Int,Num)
@@ -422,7 +425,7 @@ This is really just a shorthand for
=item *
-Slicing syntax is covered in S9. Multidimensional
+Slicing syntax is covered in S09. Multidimensional
slices will be done with semicolons between individual slice subscripts.
Each such slice is evaluated lazily.
@@ -481,12 +484,6 @@ are aliases into the C<$/> object.
The C<$#foo> notation is dead. Use C<@foo.end> or C<[-1]> instead.
(Or C<@foo.shape[$dimension]> for multidimensional arrays.)
-=item *
-
-A2 proposes C<$(...)> and C<@(...)> to interpolate arbitrary
-expressions, but these have been replaced with interpolation of curlies
-(closures).
-
=back
=head1 Names
@@ -676,8 +673,8 @@ matters type names and package names are
Typeglobs are gone. Use binding (C<:=> or C<::=>) to do aliasing.
Individual variable objects are still accessible through the
hash representing each symbol table, but you have to include the
-sigil in the variable name now: C<MyPackage::{'$foo'}> (or also
-C<< MyPackage::<$foo> >> these days).
+sigil in the variable name now: C<MyPackage::{'$foo'}> or the
+equivalent C<< MyPackage::<$foo> >>.
=item *
@@ -870,7 +867,7 @@ as they would outside the string, that i
:16<dead_beef> * 16**8
:16<dead_beef*16**8>
-It's true that only radixes that define 'e' as a digit are ambiguous that
+It's true that only radixes that define C<e> as a digit are ambiguous that
way, but with any radix it's not clear whether the exponentiator should
be 10 or the radix, and this makes it explicit:
@@ -1020,13 +1017,27 @@ just have to embed your construct inside
Bare scalar variables always interpolate in double-quotish
strings. Bare array, hash, and subroutine variables may I<never> be
-interpolated. However, any sigiled variable may start an interpolation
-if it is followed by a sequence of one or more bracketed dereferencers:
-that is, any of 1) an array subscript, 2) a hash subscript, 3) a set
-of parentheses indicating a function call, 4) any of 1 through 3 in
-their "dot" form, 5) a dot-form method call that includes argument
-parentheses, or 6) a sequence of one or more unparenthesized method
-call if followed by any of 1 through 5. In other words, this is legal:
+interpolated. However, any scalar, array, hash or subroutine variable may
+start an interpolation if it is followed by a sequence of one or more bracketed
+dereferencers: that is, any of:
+
+=over 4
+
+=item 1. An array subscript
+
+=item 2. A hash subscript
+
+=item 3. A set of parentheses indicating a function call
+
+=item 4. Any of 1 through 3 in their B<dot> form
+
+=item 5. A method call that includes argument parentheses
+
+=item 6. A sequence of one or more unparenthesized method call, followed by
any of 1 through 5
+
+=back
+
+In other words, this is legal:
"Val = $a.ord.as('%x')\n"
@@ -1172,7 +1183,7 @@ And so on.
=item *
Backslash sequences still interpolate, but there's no longer any C<\v>
-to mean "vertical tab", whatever that is... (C<\v> now match vertical
+to mean I<vertical tab>, whatever that is... (C<\v> now match vertical
whitespace in a rule.)
=item *
@@ -1452,7 +1463,7 @@ are the same as:
In contrast to assignment, binding to a hash requires a C<Hash> (or
C<Pair>) reference. Binding to a "splat" hash requires a list of pairs
or hashes, and stops processing the argument list when it runs out
-of pairs or hashes. See S6 for much more about parameter binding.
+of pairs or hashes. See S06 for much more about parameter binding.
=back
@@ -1497,7 +1508,7 @@ as ordinary named arguments.
=item *
-Properties work as detailed in A12. They're actually object
+Properties work as detailed in S12. They're actually object
attributes provided by role mixins. Compile-time properties applied
to containers and such still use the C<is> keyword, but are now called
"traits". On the other hand, run-time properties are attached to
Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Fri Feb 24 05:49:02 2006
@@ -47,7 +47,7 @@ placeholder argument:
$func("printme");
In any case, all formal parameters are the equivalent of C<my> variables
-within the block. See S6 for more on function parameters.
+within the block. See S06 for more on function parameters.
Except for such formal parameter declarations, all lexically scoped
declarations are visible from the point of declaration to the end of
@@ -654,7 +654,7 @@ since C<< prefix:<if>> > would hide C<<
=head1 Smart matching
Here is the current table of smart matches (which probably belongs in
-S3). The list is intended to reflect forms that can be recognized at
+S03). The list is intended to reflect forms that can be recognized at
compile time. If none of these forms is recognized at compile time, it
falls through to do MMD to C<< infix:<~~>() >>, which presumably
reflects similar semantics, but can finesse things that aren't exact
Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod (original)
+++ doc/trunk/design/syn/S06.pod Fri Feb 24 05:49:02 2006
@@ -860,11 +860,11 @@ produces [0,'a'],[1,'b'],[2,'c']. If yo
use C<each()> instead:
(0..2; 'a'..'c') ==> my @;tmp;
- for @;tmp.each { say }
+ for @;tmp.map { say }
and then you just get 0,'a',1,'b',2,'c'. This is good for
- for @;tmp.each -> $i, $a { say "$i: $a" }
+ for @;tmp.map -> $i, $a { say "$i: $a" }
In list context the C<@;foo> notation is really a shorthand for C<[;](@;foo)>.
@@ -914,11 +914,11 @@ which is the same as
Note that the each method is also sensitive to multislicing, so you
could also just write that as:
- (@foo; 0...).each: -> $x, $i { ...}
+ (@foo; 0...).map: -> $x, $i { ...}
Also note that these come out to identical for ordinary arrays:
- @foo.each
+ @foo.map
@foo.cat
=head2 Closure parameters
@@ -1252,7 +1252,7 @@ A value type on an array or hash specifi
my Rat %ship; # the value of each entry stores a Rat
-The key type of a hash may be specified as a shape trait--see S9.
+The key type of a hash may be specified as a shape trait--see S09.
=head2 Implementation types
