Author: larry
Date: Mon Mar 17 12:36:21 2008
New Revision: 14523
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
typos from Aaron Crane++
more (assignment, self-extending array, reification).semantics
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Mon Mar 17 12:36:21 2008
@@ -3236,7 +3236,7 @@
To force non-lazy list flattening, use the C<eager> list operator.
Don't use it on an infinite list unless you have a machine with
infinite memory, and are willing to wait a long time. To expand an
-interator object to completion, iterate it with C<< prefix:<=> >>
+iterator object to completion, iterate it with C<< prefix:<=> >>
inside an eager list:
@lines = eager =$filehandle; # read all remaining lines
Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Mon Mar 17 12:36:21 2008
@@ -1522,7 +1522,7 @@
is a list or a scalar destination.
In any case, list assignment is defined to be arbitrarily lazy,
-insofar is it basically does the obvious copying as long as there
+insofar as it basically does the obvious copying as long as there
are scalar destinations on the left or already-computed values on
the right. However, many list lvalues end with an array destination
(where assignment directly to an array can be considered a degenerate
@@ -1530,8 +1530,11 @@
continues to copy in known values immediately, but suspends when it
hits an actively iterating iterator (but not one merely passed as an
object within the list). The array location on the left is then set
-as an extensible array, with the remainder of the list on the right
-as the producer of its remaining values.
+up as a self-extending array, with the remainder of the list on the
+right as the "specs" for its remaining values, to be reified on
+demand. Hence it is legal to say:
+
+ @natural = 0..*;
(Note that when we say that an iterator in list context suspends,
it is not required to suspend immediately. When the scheduler is
@@ -1540,9 +1543,41 @@
be the case on single-core architectures with heavy context switching,
and may very well be the case even on manycore CPU architectures when
there are more iterators than cores, such that cores may still have
-to do context switching.)
+to do context switching. In any case, this is all more-or-less
+transparent to the user because in the abstract the list is all
+there, even if it hasn't been entirely computed yet.)
+
+Though elements may be reified into an array on demand, they act
+like ordinary array elements both before and after reification, as
+far as the user is concerned. These elements may be written to if
+the underlying container type supports it:
+
+ @unnatural = 0..*;
+ @unnatural[42] = "Life, the Universe, and Everything";
+
+Note that, unlike assignment, binding replaces the container,
+so the following fails because a range object cannot be subscripted:
+
+ @natural := 0..*; # bind a Range object
+ @natural[42] = "Life, the Universe, and Everything"; # FAILS
+
+but this succeeds:
+
+ @unnatural := [0..*]; # bind an Array object
+ @unnatural[42] = "Life, the Universe, and Everything"; # ok
+
+It is erroneous to make use of any side effects of reification, such
+as movement of a file pointer, since different implementations may
+have different batch semantics, and in any case the unreified part
+of the list already "belongs" to the array.
+
+When a self-extending array is asked for its count of elements, it
+is allowed to return C<+Inf> without blowing up if it can determine
+by inspection that its unreified parts contain any infinite lists.
+If it cannot determine this, it is allowed for it to use all your
+memory, and then some. C<:)>
-Assignment to a hash is not lazy.
+Assignment to a hash is not lazy (probably).
=item *
