Author: lwall
Date: 2009-09-21 22:57:15 +0200 (Mon, 21 Sep 2009)
New Revision: 28344
Modified:
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S09-data.pod
Log:
[S03,S09]
Range objects are now primarily intervals in Ccmp
Extend dwimminess of series to handle steps and limits readably
:by is deemed Too Ugly and is now dead, David Green++
Use series operator to replace :by semantics more readably
Range objects used as lists now simply mutate .. to ...
(taking into account ^ though)
Alpha ranges must now match endpoint using !after semantics on non-eqv
Simplify range semantics when used as subscripts
Kill unshifty negative subscript lvalues as too error prone
Spec way to declare modular subscripts
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2009-09-21 20:44:52 UTC (rev 28343)
+++ docs/Perl6/Spec/S03-operators.pod 2009-09-21 20:57:15 UTC (rev 28344)
@@ -14,8 +14,8 @@
Created: 8 Mar 2004
-Last Modified: 2 Sep 2009
-Version: 172
+Last Modified: 21 Sep 2009
+Version: 173
=head1 Overview
@@ -270,7 +270,7 @@
Pair composers
-:by(2)
+:limit(5)
:!verbose
=item *
@@ -1413,7 +1413,7 @@
Adverbs will generally attach the way you want when you say things like
-1 .. $x+2 :by(2)
+1 op $x+2 :mod($x)
The proposed internal testing syntax makes use of these precedence rules:
@@ -1751,10 +1751,11 @@
More typically the function is unary, in which case any extra values
in the list may be construed as human-readable documentation:
-0,2,4 ... { $_ + 2 }# same as 1..*:by(2)
+0,2,4 ... { $_ + 2 }# all the evens
+0,2,4 ... *+2 # same thing
a b c ... { .succ } # same as 'a'..*
-The function need not be monotonic, of course:
+The function need not be monotoniccaly increasing, of course:
1 ... { -$_ } # 1, -1, 1, -1, 1, -1...
False ... prefix:! # False, True, False...
@@ -1763,7 +1764,7 @@
() ... { rand } # list of random numbers
-The function may also be slurpy (*-ary), in which case all the
+The function may also be slurpy (n-ary), in which case all the
preceding values are passed in (which means they must all be cached
by the operator, so performance may suffer).
@@ -1773,26 +1774,24 @@
1,1 ... { $^a + 1, $^b * 2 } # 1,1,2,2,3,4,4,8,5,16,6,32...
If the right operand is C* (Whatever) and the sequence is obviously
-arithmetic or geometric, the appropriate function is deduced:
+arithmetic or geometric (from examining its Ilast 3 values), the appropriate
function is deduced:
1, 3, 5 ... * # odd numbers
1, 2, 4 ... * # powers of 2
-Conjecture: other such patterns may be recognized in the future,
-depending on which unrealistic benchmarks we want to run faster. C:)
+If there are only two values so far, C* assumes an arithmentic
+progression. If there is only one value (or if the final values do
+not support the requisite arithmetic), C* assumes incrementation
+via C.succ. Hence these come out the same:
-Note: the yada operator is recognized only where a term is expected.
-This operator may only be used where an infix is expected. If you
-put a comma before the C... it will be taken as a yada list operator
-expressing the desire to fail when the list reaches that point:
+1..*
+1...*
+1,2,3...*
-1..20, ... I only know up to 20 so far mister
+If list on the left is CNil, C* will return a single CNil.
-If the yada operator finds a closure for its argument at compile time,
-it should probably whine about the fact that it's difficult to turn
-a closure into an error message. Alternately, we could treat
-an ellipsis as special when it follows a comma to better support
-traditional math notation.
+Conjecture: other such patterns may be recognized in the future,
+depending on which unrealistic benchmarks we want to run faster. C:)
The function may choose to terminate its list by returning ().
Since this operator is list associative, an inner function may be
@@ -1809,10 +1808,83 @@
10,20,30,40,50,60,70,80,90,
100,200,300,400,500,600,700,800,900
+If the right operand is a list and the first element of the list is
+a function or C*, the second element of the list imposes a limit
+on the prior sequence. (The limit is inclusive on an exact match,
+and in general is compared using C!after semantics, so an inexact
+match is *not* included.) Hence the preceding example may be rewritten
+
+1 ... * + 1, 9
+10 ... * + 10, 90
+100 ... * + 100, 1000
+
+or as
+
+1, 2, 3 ... *,
+10, 20, 30 ... *,
+100, 200, 300 ... *, 1000
+
+In the latter case the preceding 3 elements are used to deduce
+the correct arithmetic progression, so the 3, 30, and 300
+terms are necessary.
+
+If the first element of the list is numeric, a C* is assumed
+before it, and the first
