[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-language
Subject:    r29580 - docs/Perl6/Spec misc
From:       pugs-commits () feather ! perl6 ! nl
Date:       2010-01-23 0:04:31
Message-ID: 20100123000431.14439.qmail () feather ! perl6 ! nl
[Download RAW message or body]

Author: lwall
Date: 2010-01-23 01:04:30 +0100 (Sat, 23 Jan 2010)
New Revision: 29580

Modified:
   docs/Perl6/Spec/S03-operators.pod
   docs/Perl6/Spec/S07-iterators.pod
   misc/pm.txt
Log:
[S03,S07] more Pm-16 refinements


Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod	2010-01-22 18:55:17 UTC (rev 29579)
+++ docs/Perl6/Spec/S03-operators.pod	2010-01-23 00:04:30 UTC (rev 29580)
@@ -1962,11 +1962,23 @@
     'Z' ... -> $old { my $new = $old.pred; $old ne 'A' and $new !before 'A' ?? $new !! () }
 
 For purposes of deciding when to terminate the eager part of a 'mostly
-eager' list, any series that terminates with an exact value (or that
-starts another series with exact values) is considered finite, but any
-other series that ends with a closure or C<*> is considered infinite
-(even if extended with a closure that has internal logic to terminate).
+eager' list, any series that terminates with an exact value (or
+that starts another series with exact values) is considered finite,
+but any other series that ends with a closure or C<*> (that is,
+without a following final value) is considered to be of unknowable
+length (even if extended with a closure that has internal logic to
+terminate).  However, by the definition of "mostly eager" in L<S07>,
+the implementation may be able to determine that such a sequence is
+finite by conjectural evaluation; such workahead cannot, of course,
+prove that a sequence is infinite without running a Very Long Time.
+Note also that, by using the form that specifies both a closure and
+a final value, it is possible to write series that appears to be
+finite but that never actually reaches its final value before resources
+are exhausted; such a series will be treated as finite, but eventually
+come to grief:
 
+    @a = 1 ... *+0.00000000000000000000000000000000000001, 2;  # crunch
+
 =back
 
 Many of these operators return a list of C<Parcel>s, which depending on

Modified: docs/Perl6/Spec/S07-iterators.pod
===================================================================
--- docs/Perl6/Spec/S07-iterators.pod	2010-01-22 18:55:17 UTC (rev 29579)
+++ docs/Perl6/Spec/S07-iterators.pod	2010-01-23 00:04:30 UTC (rev 29580)
@@ -14,8 +14,8 @@
 
     Created: 27 Nov 2008
 
-    Last Modified: 21 Jan 2010
-    Version: 6
+    Last Modified: 22 Jan 2010
+    Version: 7
 
 =head1 Laziness and Eagerness
 
@@ -42,18 +42,46 @@
 
 =item Mostly Lazy
 
-Try to obtain available items without causing eager evaluation of
-other lazy objects.  However, the implementation is allowed to do batching
-for efficiency.
+Try to obtain available items without causing eager evaluation of other
+lazy objects.  However, the implementation is allowed to do batching
+for efficiency.  The programmer must not rely on circular side effects when
+the implementation is working ahead like this, or the results will
+be indeterminate.  (However, this does not rule out pure I<definitional>
+circularity: if a list is bound to the name of an array, earlier
+array values may be used in the definition of subsequent values.)
 
 =item Mostly Eager
 
-Obtain all items, but does not try to eagerly evaluate when known to
-be infinite.
+Obtain all "easy" items, defined as all leading items that are (easily)
+provable to represent a finite number of values (even if the exact
+number is not known in advance).  The remainder of the items are
+left for lazy evaluation.  For constructs that are not known either
+to be finite or infinite, the implementation is allowed, but not
+required, to work ahead some number of elements in a batching mode.
+If such a batch proves to terminate, the list may continue to with
+eager evaluation of subsequent elements.  As with the "mostly lazy"
+case, the programmer must not depend on circular side effects in
+any situation where the implementation is allowed to work ahead.
+Note that there are no language-defined limits on the amount of
+conjectural evaluation allowed, up to the size of available memory;
+however, an implementation may allow the arbitrary limitation of
+workahead by use of pragams.
 
+I/O from a file may generally be assumed to be finite, but I/O
+from a socket may not.  However, since the definition of "finite"
+is somewhat dependent on available memory, a file that is too big
+may be reasonably be treated lazily.  In any case, there should be no
+profound semantic differences between "mostly lazy" and "mostly eager".
+They are primarily just hints to the implementation as to whether
+you are likely to want to use all the values in the list.  Nothing
+transactional should be allowed to depend on the difference.
+
 =item Strictly Eager
 
-Obtain all items, fail in data structures known to be infinite.
+Obtain all items, failing immediately with an appropriate message
+if asked to evaluate any data structures known to be infinite.
+(Data structures that are effectively infinite but not provably
+so will likely exhaust memory instead.)
 This behavior is generally available only by pragma or by explicit
 programming primitives.
 
@@ -61,8 +89,8 @@
 
 It's important to realize that the responsibility of determining the
 level of laziness/eagerness in each operation is external to each lazy
-object, the runtime, depending on which operation is being performed,
-is going to assume the level of laziness and perform the needed
+object; the runtime, depending on which operation is being performed,
+is going to assume an appropriate level of laziness and perform the needed
 operations to apply that level.
 
 =head2 The laziness level of some common operations

Modified: misc/pm.txt
===================================================================
--- misc/pm.txt	2010-01-22 18:55:17 UTC (rev 29579)
+++ misc/pm.txt	2010-01-23 00:04:30 UTC (rev 29580)
@@ -11,23 +11,6 @@
     act more like $a.list  than list($a).)
 
 
-Pm-16:  S03:1996 looks like a fossil, or at least inconsistent 
-    with S07:72.  Any clarifications?
-
-See r29571.
-
-    [Pm]  Okay, that helps, but there still seems to be an
-    inconsistency.  r29571 says that list assignment is "mostly
-    eager", but then says it evaluates leading iterators as long as 
-    they're known to be finite.  In other words, it suspends on the
-    first iterator that is not provably finite.  But S07 says that 
-    "mostly eager" obtains all items until reaching a value that is 
-    known to be infinite.  "Not provably finite" is not the same as 
-    "known to be infinite"; the S03 interpretation would stop obtaining 
-    values on anything that _might_ be infinite, the S07 interpretation 
-    would eagerly obtain values until it reaches something that is 
-    _known_ to be (or declares itself to be) infinite.
-
 ===========================================================
 
 Answered questions:
@@ -272,6 +255,21 @@
 
 See r29571.
 
+    [Pm]  Okay, that helps, but there still seems to be an
+    inconsistency.  r29571 says that list assignment is "mostly
+    eager", but then says it evaluates leading iterators as long as 
+    they're known to be finite.  In other words, it suspends on the
+    first iterator that is not provably finite.  But S07 says that 
+    "mostly eager" obtains all items until reaching a value that is 
+    known to be infinite.  "Not provably finite" is not the same as 
+    "known to be infinite"; the S03 interpretation would stop obtaining 
+    values on anything that _might_ be infinite, the S07 interpretation 
+    would eagerly obtain values until it reaches something that is 
+    _known_ to be (or declares itself to be) infinite.
+
+"Mostly Eager" is now allowed to slack off after chewing on (or refusing
+to chew on) something that is 'not provably infinite'.
+
 ----------------------
 
 Pm-17:  Are the builtin types such as C<Num>, C<Int>, C<Rat>, 

[prev in list] [next in list] [prev in thread] [next in thread]