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>,
