Re: [perl #69194] rakudo 2009-08 and when with lists
On 2009-Sep-20, at 12:48 am, Larry Wall wrote: Yes, I think it's fair to say that either list context OR a :by turns a Range into a RangeIterator that matches like a list. Hence, this ought to match: (1,3,5) ~~ (1..5 :2by) OK; but I still have to ask why it returns a RangeIterator instead of a SeriesIterator or any other plain Iterator. Is there some reason to make :by work on Ranges that way instead of being, say, an adverb on ...? I can see that it's obvious and useful to get a list by filling in the values between two endpoints, but that also applies to a pair, or a list of two items. Having :by effectively work like a list at least reduces the confusion in the case of numbers, but we're still left with a puzzle when it comes to strings: Is b ~~ a..az false because it's not the case that a b az, or is it true because expanding the list produces a, b, c, ... ax, ay, az? The former according to spec; but the latter according to someone who expects a parallel with ints. (Apparently Rakudo expects that too, at least for the moment.) Of course, in this case :by doesn't help because there is only one way to increment strings. If we give up the Range/RangeIterator duality, we still have the two different concepts, but I think people will be less tempted to try making them line up together mentally. (Different things should look different.) I don't see that we would lose any functionality (make the :by features work with ...; or keep .. and ... as two ways to make series, and use infix:to for Ranges; or anything else that distinguishes ranges from iterators). What's the big advantage in keeping it the way it is? -David
Re: r28339 - docs/Perl6/Spec
On Mon, Sep 21, 2009 at 12:01 PM, pugs-comm...@feather.perl6.nl wrote: @@ -65,9 +65,9 @@ The basic underlying concept is that a Parcel behaves much like a list, but it doesn't enforce any context, in a way that no flattening -or coercion is made. When you use the Positional API on a Parcel, it -will include all the listed items, no matter they look like named -arguments or positional arguments. In example: +or coercion is done. When you use the Positional API on a Parcel, it +will include all the listed items, wether they look like named +arguments or positional arguments. For example: 1, 2, :ab the second line should be: will include all of the listed items, whether they look like named -- Jonathan Dataweaver Lang
r28340 - docs/Perl6/Spec
Author: ruoso Date: 2009-09-21 21:21:37 +0200 (Mon, 21 Sep 2009) New Revision: 28340 Modified: docs/Perl6/Spec/S08-capture.pod Log: [S08] another typo by mberends++, s/list/array/ as pointed by PerlJam++ and pmichaud++ Modified: docs/Perl6/Spec/S08-capture.pod === --- docs/Perl6/Spec/S08-capture.pod 2009-09-21 19:01:22 UTC (rev 28339) +++ docs/Perl6/Spec/S08-capture.pod 2009-09-21 19:21:37 UTC (rev 28340) @@ -66,7 +66,7 @@ The basic underlying concept is that a Parcel behaves much like a list, but it doesn't enforce any context, in a way that no flattening or coercion is done. When you use the Positional API on a Parcel, it -will include all the listed items, wether they look like named +will include all the listed items, whether they look like named arguments or positional arguments. For example: 1, 2, :ab @@ -133,7 +133,8 @@ say $a[1;1;1]; -Note that if you assign that parcel to list, it will be flattened, so: +Note that if you assign that parcel to an array, it will be flattened, +so: my @a = 1, (2, (3, 4)); say @a[3]; @@ -144,7 +145,7 @@ say @a[1;1;1]; -As the element 1 of the list @a is not a Capture or a Parcel, it is +As the element 1 of the array @a is not a Capture or a Parcel, it is not possible for the .[] operator to traverse it. [Conjecture: It is still not clear if the multidimensional access
r28341 - docs/Perl6/Spec
Author: ruoso Date: 2009-09-21 21:58:46 +0200 (Mon, 21 Sep 2009) New Revision: 28341 Modified: docs/Perl6/Spec/S08-capture.pod Log: [S08] enforce correct precedence, as pointed out by pmichaud++ Modified: docs/Perl6/Spec/S08-capture.pod === --- docs/Perl6/Spec/S08-capture.pod 2009-09-21 19:21:37 UTC (rev 28340) +++ docs/Perl6/Spec/S08-capture.pod 2009-09-21 19:58:46 UTC (rev 28341) @@ -89,7 +89,7 @@ regular use of inline declarations consistent, let's say you do the following: - my $a = 0, :ab, 2; + my $a = (0, :ab, 2); say $a[2]; If we had Capture and Parcel as the same data structure, you wouldn't @@ -158,7 +158,7 @@ On the other hand, if you bind a parcel to a variable, it doesn't really matter which sigil it uses: - my @a := 1, (2, (3, 4)); + my @a := (1, (2, (3, 4))); say @a[1;1;1]; # 4 say @a[3]; # failure @@ -212,11 +212,11 @@ In order to use the context deferral in your code, you need to use the capture sigil, which can be presented in two forms: - my ¢a = 1, (2, (3, 4)); + my ¢a = (1, (2, (3, 4))); or - my @%a = 1, (2, (3, 4)); + my @%a = (1, (2, (3, 4))); The latter is provided as an alternative for situations where you want to preserve the code in 7-bits only.
r28342 - docs/Perl6/Spec
Author: ruoso
Date: 2009-09-21 22:01:50 +0200 (Mon, 21 Sep 2009)
New Revision: 28342
Modified:
docs/Perl6/Spec/S08-capture.pod
Log:
[S08] enforce correct precedence, as pointed out by pmichaud++
Modified: docs/Perl6/Spec/S08-capture.pod
===
--- docs/Perl6/Spec/S08-capture.pod 2009-09-21 19:58:46 UTC (rev 28341)
+++ docs/Perl6/Spec/S08-capture.pod 2009-09-21 20:01:50 UTC (rev 28342)
@@ -115,7 +115,7 @@
by the operators is whatever the item inside it implements Parcel or
Capture. For instance:
- my $a = 1, (2, (3, 4));
+ my $a = (1, (2, (3, 4)));
say $a[1];
In that case, you'll get 2, (3, 4) (or whatever is implemented in
@@ -165,14 +165,14 @@
Captures and Parcels are seen the same way regarding
multidimensionality, for instance:
- my $a = (map { $_ * 2 }, 1..5),(map { $_ / 2 }, 1..5);
+ my $a = ((map { $_ * 2 }, 1..5),(map { $_ / 2 }, 1..5));
say $a[0;0]; # 2
say $a[1;0]; # 0.5
The same way, if each map closure returns more than one item inside
its capture:
- my $a = (map { $_ * 2, $_ / 2 }, 1..5),(map { $_ / 2, $_ * 2 }, 1..5);
+ my $a = ((map { $_ * 2, $_ / 2 }, 1..5),(map { $_ / 2, $_ * 2 }, 1..5));
say $a[0;0;0]; # 2
say $a[0;0;1]; # 0.5
say $a[1;0;0]; # 0.5
r28344 - docs/Perl6/Spec
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
r28345 - docs/Perl6/Spec
Author: moritz
Date: 2009-09-21 23:01:49 +0200 (Mon, 21 Sep 2009)
New Revision: 28345
Modified:
docs/Perl6/Spec/S08-capture.pod
Log:
[S08] use POD markup where appropriate
Also use non-breaking space for Perl?\194?\1605 and Perl?\194?\1606
Modified: docs/Perl6/Spec/S08-capture.pod
===
--- docs/Perl6/Spec/S08-capture.pod 2009-09-21 20:57:15 UTC (rev 28344)
+++ docs/Perl6/Spec/S08-capture.pod 2009-09-21 21:01:49 UTC (rev 28345)
@@ -21,7 +21,7 @@
Unlike most programming languages, the data structure that is used to
send the parameters into a routine invocation (be it a method or a
sub) is exposed to the language as a built-in type like any
-other. This represents a very important aspect of the Perl 6 runtime
+other. This represents a very important aspect of the Perl 6 runtime
requirements.
Additionally to the fact that this data structure is visible in the
@@ -33,10 +33,10 @@
Of course the runtime can cheat whenever it knows the capture is
implemented by its own internal data structure for optimization
purposes, but it should allow the use of foreign types when invoking a
-routine, as long as the object says true to .^does(Capture).
+routine, as long as the object says true to C.^does(Capture).
Captures and Parcels are also the basis for the multidimensionality of
-lists in Perl 6. Unlike Perl 5, no flattening happens unless it's
+lists in Perl 6. Unlike Perl 5, no flattening happens unless it's
explicitly required by the user, which is done by enforcing the List
context. If you use the scalar context the dimensionality should be
preserved.
@@ -48,31 +48,31 @@
useful to avoid unwanted flattening as well as avoiding the DWIMmy
features that might change the capture's behavior.
-This is the main point of why Capture and Parcel replace Perl 5
+This is the main point of why Capture and Parcel replace Perl 5
references, they allow you to send data untouched from one place to
-another. The second reason is that as in Perl 6 everything is an
+another. The second reason is that as in Perl 6 everything is an
object, there isn't really pass-by-value anymore, you're always
sending a reference, Captures and Parcels simply carry other objects
without enforcing any context on them.
=head1 Capture or Parcel
-While a Capture is the object that holds the parameters sent to a
-routine (positional and named), a Parcel is a more fundamental data
+While a CCapture is the object that holds the parameters sent to a
+routine (positional and named), a CParcel is a more fundamental data
structure that doesn't really differentiate named arguments from
positional arguments (but it still lets you access the named ones by
their name).
The basic underlying concept is that a Parcel behaves much like a
list, but it doesn't enforce any context, in a way that no flattening
-or coercion is done. When you use the Positional API on a Parcel, it
+or coercion is done. When you use the CPositional API on a Parcel, it
will include all the listed items, whether they look like named
arguments or positional arguments. For example:
1, 2, :ab
The Parcel represented here has 3 positional items and allows you to
-access the element 'a' through the Associative interface. A Parcel
+access the element 'a' through the CAssociative interface. A Parcel
might be statically converted to a Capture if it's clear to the parser
that it's being used as the arguments to a routine call.
@@ -83,7 +83,7 @@
In the call to the routine foo, there are only two positional
arguments and one named argument, and you won't be able to find b
-from the Positional interface, but only from the Associative.
+from the CPositional interface, but only from the Associative.
The differentiation from Parcel and Capture is important to keep the
regular use of inline declarations consistent, let's say you do the
@@ -93,15 +93,15 @@
say $a[2];
If we had Capture and Parcel as the same data structure, you wouldn't
-get 2 as the result of the above code, because there are only two
+get C2 as the result of the above code, because there are only two
positional arguments, not three. Using the same example:
sub foo($p1, $p2, :$a) {...}
foo(|$a);
In that case, the Parcel is converted into a Capture, and therefore
-the pair :ab is no longer visible as a positional argument, only as
-named.
+the pair C :ab is no longer visible as a positional argument,
+only as named.
Note that once you convert a Parcel into a Capture, you won't be able
to get the original Parcel again, because a Capture doesn't hold the
@@ -110,7 +110,7 @@
=head1 Multidimensionality
Probably the most important task of Parcels and Captures is to
-implement the multidimensionality of lists in Perl 6, this means that
+implement the multidimensionality of lists in Perl 6, this means that
the barrier used to detect the dimensionality of the data structures
by the operators is
r28346 - docs/Perl6/Spec
Author: lwall Date: 2009-09-21 23:12:29 +0200 (Mon, 21 Sep 2009) New Revision: 28346 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] missing commas Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-09-21 21:01:49 UTC (rev 28345) +++ docs/Perl6/Spec/S03-operators.pod 2009-09-21 21:12:29 UTC (rev 28346) @@ -1814,8 +1814,8 @@ 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 +1 ... * + 1, 9, +10 ... * + 10, 90, 100 ... * + 100, 1000 or as
r28347 - docs/Perl6/Spec
Author: lwall
Date: 2009-09-21 23:26:58 +0200 (Mon, 21 Sep 2009)
New Revision: 28347
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
typos
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2009-09-21 21:12:29 UTC (rev 28346)
+++ docs/Perl6/Spec/S03-operators.pod 2009-09-21 21:26:58 UTC (rev 28347)
@@ -1755,7 +1755,7 @@
0,2,4 ... *+2 # same thing
a b c ... { .succ } # same as 'a'..*
-The function need not be monotoniccaly increasing, of course:
+The function need not be monotonically increasing, of course:
1 ... { -$_ } # 1, -1, 1, -1, 1, -1...
False ... prefix:! # False, True, False...
@@ -1779,7 +1779,7 @@
1, 3, 5 ... * # odd numbers
1, 2, 4 ... * # powers of 2
-If there are only two values so far, C* assumes an arithmentic
+If there are only two values so far, C* assumes an arithmetic
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:
r28348 - docs/Perl6/Spec
Author: lwall Date: 2009-09-22 00:09:17 +0200 (Tue, 22 Sep 2009) New Revision: 28348 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] revise thinko spotted by spinclad++ Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-09-21 21:26:58 UTC (rev 28347) +++ docs/Perl6/Spec/S03-operators.pod 2009-09-21 22:09:17 UTC (rev 28348) @@ -1825,8 +1825,8 @@ 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. +the correct arithmetic progression, so the 30 and 300 +terms are necessary to prevent interpretation as geometric. If the first element of the list is numeric, a C* is assumed before it, and the first element is again taken as the limit.
r28351 - docs/Perl6/Spec
Author: lwall
Date: 2009-09-22 03:53:43 +0200 (Tue, 22 Sep 2009)
New Revision: 28351
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] more clarifications of autogenerated generator functions, pmichaud++
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2009-09-21 23:28:11 UTC (rev 28350)
+++ docs/Perl6/Spec/S03-operators.pod 2009-09-22 01:53:43 UTC (rev 28351)
@@ -1779,21 +1779,57 @@
1, 3, 5 ... * # odd numbers
1, 2, 4 ... * # powers of 2
-If there are only two values so far, C* assumes an arithmetic
-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:
+That is, supposing we call the last three numbers C$a, C$b, and
+C$c, and then define:
-1..*
-1...*
-1,2,3...*
+$ab = $b - $a;
+$bc = $c - $b;
-If list on the left is CNil, C* will return a single CNil.
+If C$ab == $bc and C$ab is not zero, then we deduce an arithmetic
+progression determined by the function C*+$ab. If C$ab is zero,
+and the three values look like numbers, then the function is C*+0.
+If they do not look like numbers, then the function selected is either
+C*.succ or C*.pred depending on whether C$b cmp $c appears to be
+Increasing or Decreasing. If Ccmp returns Same then an identity
+function is assumed.
-Conjecture: other such patterns may be recognized in the future,
-depending on which unrealistic benchmarks we want to run faster. C:)
+If C$ab != $bc and Cnone($a,$b,$c) == 0, then a similar calculation
+is done using division rather than subtraction to determine whether
+a geometric progression is warranted. Define:
-The function may choose to terminate its list by returning ().
+$ab = $b / $a;
+$bc = $c / $b;
+
+If the two quotients are equal (and finite), then a geometric
+function of C{$_ * $bc} is deduced.
+
+If there are only two values in the list so far, C$a and C$b, and the
difference C$ab
+is non-zero, we assume an arithmetic progression of C*+$ab. If C$ab
+is zero, then again it depends on whether the two values look like
+numbers whether we use C*+0 or C*.succ/C*.pred.
+
+If there is only one value, C* always assumes incrementation via
+C.succ. (This may be forced to C.pred by examination of a limit,
+as specified below.) Hence these come out the same:
+
+1 .. *
+1 ... *
+1,2 ... *
+1,2,3 ... *
+1 2 3 ... * # (but note: first 3 elements are of Str type!)
+
+Likewise these come out the same:
+
+'a' .. *
+'a' ... *
+'a','b' ... *
+'a','b','c' ... *
+a b c ... *
+
+If the list on the left is CNil, C* uses the function {Nil}
+
+When an explicit function is used, it
+may choose to terminate its list by returning ().
Since this operator is list associative, an inner function may be
followed by a C... and another function to continue the list,
and so on. Hence,
@@ -1811,7 +1847,7 @@
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
+and in general is compared using C!after or C!before semantics, so an
inexact
match is *not* included.) Hence the preceding example may be rewritten
1 ... * + 1, 9,
@@ -1828,7 +1864,7 @@
the correct arithmetic progression, so the 30 and 300
terms are necessary to prevent interpretation as geometric.
-If the first element of the list is numeric, a C* is assumed
+If the first element of the right-hand list is numeric, a C* is assumed
before it, and the first element is again taken as the limit.
So the preceding example reduces to:
@@ -1839,6 +1875,16 @@
These rules may seem complicated, but they're essentially just replicating
what a human does naturally when you say and so on.
+The exact function deduced depends on the direction from the final
+value on the left to the limit value on the right. If the limit is
+greater than the last value according to Ccmp, then comparisons
+are done with C!after. If the limit is less, then comparisons are
+done with C!before, and if the generator function was C.succ, it
+is switched to C.pred. Hence we have this difference:
+
+'z' .. 'a' # null range
+'z' ... 'a' # z y x ... a
+
Note that the sequence
1.0 ... *+0.2, 2.0
@@ -1881,10 +1927,27 @@
To preserve Perl 5 semantics, you'd need something like:
-'A' ... { my $new = $_.succ; $_ ne $endpoint and $new.chars = 1 ?? $new
!! () }
+'A' ... - $old { my $new = $old.succ; $old ne $endpoint and $new.chars =
1 ?? $new !! () }
But since lists are lazy in Perl 6, we don't try to protect the user this way.
+The astute reader will note that
+
+'A' ... 'Z'
+
+doesn't terminate with a simple C!after test
