Revision 28351

Date:
2009/09/22 01:53:43
Author:
lwall
Revision Log:
[S03] more clarifications of autogenerated generator functions, pmichaud++
Files:

Legend:

 
Added
 
Removed
 
Modified

  • docs/Perl6/Spec/S03-operators.pod

     
    1779 1779 1, 3, 5 ... * # odd numbers
    1780 1780 1, 2, 4 ... * # powers of 2
    1781 1781
    1782 If there are only two values so far, C<*> assumes an arithmetic
    1783 progression. If there is only one value (or if the final values do
    1784 not support the requisite arithmetic), C<*> assumes incrementation
    1785 via C<.succ>. Hence these come out the same:
    1782 That is, supposing we call the last three numbers C<$a>, C<$b>, and
    1783 C<$c>, and then define:
    1786 1784
    1787 1..*
    1788 1...*
    1789 1,2,3...*
    1785 $ab = $b - $a;
    1786 $bc = $c - $b;
    1790 1787
    1791 If list on the left is C<Nil>, C<*> will return a single C<Nil>.
    1788 If C<$ab == $bc> and C<$ab> is not zero, then we deduce an arithmetic
    1789 progression determined by the function C<*+$ab>. If C<$ab> is zero,
    1790 and the three values look like numbers, then the function is C<*+0>.
    1791 If they do not look like numbers, then the function selected is either
    1792 C<*.succ> or C<*.pred> depending on whether C<$b cmp $c> appears to be
    1793 Increasing or Decreasing. If C<cmp> returns Same then an identity
    1794 function is assumed.
    1792 1795
    1793 Conjecture: other such patterns may be recognized in the future,
    1794 depending on which unrealistic benchmarks we want to run faster. C<:)>
    1796 If C<$ab != $bc> and C<none($a,$b,$c) == 0>, then a similar calculation
    1797 is done using division rather than subtraction to determine whether
    1798 a geometric progression is warranted. Define:
    1795 1799
    1796 The function may choose to terminate its list by returning ().
    1800 $ab = $b / $a;
    1801 $bc = $c / $b;
    1802
    1803 If the two quotients are equal (and finite), then a geometric
    1804 function of C<{$_ * $bc}> is deduced.
    1805
    1806 If there are only two values in the list so far, C<$a> and C<$b>, and the difference C<$ab>
    1807 is non-zero, we assume an arithmetic progression of C<*+$ab>. If C<$ab>
    1808 is zero, then again it depends on whether the two values look like
    1809 numbers whether we use C<*+0> or C<*.succ>/C<*.pred>.
    1810
    1811 If there is only one value, C<*> always assumes incrementation via
    1812 C<.succ>. (This may be forced to C<.pred> by examination of a limit,
    1813 as specified below.) Hence these come out the same:
    1814
    1815 1 .. *
    1816 1 ... *
    1817 1,2 ... *
    1818 1,2,3 ... *
    1819 <1 2 3> ... * # (but note: first 3 elements are of Str type!)
    1820
    1821 Likewise these come out the same:
    1822
    1823 'a' .. *
    1824 'a' ... *
    1825 'a','b' ... *
    1826 'a','b','c' ... *
    1827 <a b c> ... *
    1828
    1829 If the list on the left is C<Nil>, C<*> uses the function {Nil}
    1830
    1831 When an explicit function is used, it
    1832 may choose to terminate its list by returning ().
    1797 1833 Since this operator is list associative, an inner function may be
    1798 1834 followed by a C<...> and another function to continue the list,
    1799 1835 and so on. Hence,
    … …  
    1811 1847 If the right operand is a list and the first element of the list is
    1812 1848 a function or C<*>, the second element of the list imposes a limit
    1813 1849 on the prior sequence. (The limit is inclusive on an exact match,
    1814 and in general is compared using C<!after> semantics, so an inexact
    1850 and in general is compared using C<!after> or C<!before> semantics, so an inexact
    1815 1851 match is *not* included.) Hence the preceding example may be rewritten
    1816 1852
    1817 1853 1 ... * + 1, 9,
    … …  
    1828 1864 the correct arithmetic progression, so the 30 and 300
    1829 1865 terms are necessary to prevent interpretation as geometric.
    1830 1866
    1831 If the first element of the list is numeric, a C<*> is assumed
    1867 If the first element of the right-hand list is numeric, a C<*> is assumed
    1832 1868 before it, and the first element is again taken as the limit.
    1833 1869 So the preceding example reduces to:
    1834 1870
    … …  
    1839 1875 These rules may seem complicated, but they're essentially just replicating
    1840 1876 what a human does naturally when you say "and so on".
    1841 1877
    1878 The exact function deduced depends on the direction from the final
    1879 value on the left to the limit value on the right. If the limit is
    1880 greater than the last value according to C<cmp>, then comparisons
    1881 are done with C<!after>. If the limit is less, then comparisons are
    1882 done with C<!before>, and if the generator function was C<.succ>, it
    1883 is switched to C<.pred>. Hence we have this difference:
    1884
    1885 'z' .. 'a' # null range
    1886 'z' ... 'a' # z y x ... a
    1887
    1842 1888 Note that the sequence
    1843 1889
    1844 1890 1.0 ... *+0.2, 2.0
    … …  
    1881 1927
    1882 1928 To preserve Perl 5 semantics, you'd need something like:
    1883 1929
    1884 'A' ... { my $new = $_.succ; $_ ne $endpoint and $new.chars <= 1 ?? $new !! () }
    1930 'A' ... -> $old { my $new = $old.succ; $old ne $endpoint and $new.chars <= 1 ?? $new !! () }
    1885 1931
    1886 1932 But since lists are lazy in Perl 6, we don't try to protect the user this way.
    1887 1933
    1934 The astute reader will note that
    1935
    1936 'A' ... 'Z'
    1937
    1938 doesn't terminate with a simple C<!after> test either. The actual function used
    1939 is something like:
    1940
    1941 'A' ... -> $old { my $new = $old.succ; $old ne 'Z' and $new !after 'Z' ?? $new !! () }
    1942
    1943 Likewise, since Z comes after A:
    1944
    1945 'Z' ... 'A'
    1946
    1947 uses the function:
    1948
    1949 'Z' ... -> $old { my $new = $old.pred; $old ne 'A' and $new !before 'A' ?? $new !! () }
    1950
    1888 1951 =back
    1889 1952
    1890 1953 Many of these operators return a list of C<Capture>s, which depending on