Revision 28334

Date:
2009/09/21 01:28:27
Author:
lwall
Revision Log:
[S02] clarification of run-time-ish nature of (* * *) requested by JimmyZ++
Files:

Legend:

 
Added
 
Removed
 
Modified

  • docs/Perl6/Spec/S02-bits.pod

     
    13 13
    14 14 Created: 10 Aug 2004
    15 15
    16 Last Modified: 5 Sep 2009
    17 Version: 179
    16 Last Modified: 20 Sep 2009
    17 Version: 180
    18 18
    19 19 This document summarizes Apocalypse 2, which covers small-scale
    20 20 lexical items and typological issues. (These Synopses also contain
    … …  
    832 832
    833 833 { $_ - 1 }
    834 834
    835 Likewise, the single dispatcher recognizes C<*.meth> and returns C<{ $_.meth }>,
    836 so it can be used where patterns are expected:
    835 This closure is officially returned at run time, so it is I<not>
    836 subject to the rule that bare closures execute immediately when used as
    837 a statement. However, in most cases the result of a multiple dispatch
    838 can be determined at compile time, so the compiler is expected to
    839 optimize away the run-time call. Hence, despite the fact that the
    840 inside of parentheses is considered a statement, if you say
    837 841
    842 (* + 7)(3) # 10
    843
    844 the generated C< { $_ + 7 } > closure is returned uncalled
    845 by those parentheses and then invoked by the C<.(3)> postfix. In
    846 contrast,
    847
    848 ( { $_ + 7 } )(3)
    849
    850 evaluates the bare block immediately with whatever C<$_> is already in
    851 scope, and then fails because a number doesn't know how to respond
    852 to the C<.(3)> invocation.
    853
    854 Likewise, the single dispatcher offically recognizes C<*.meth> at run time
    855 and returns C<{ $_.meth }>, so it can be used where patterns are expected:
    856
    838 857 @primes = grep *.prime, 2..*;
    839 858
    859 This also should be optimized to a closure by the compiler. Basically,
    860 dispatches to C<Whatever> are assumed to be subject to constant folding.
    861
    840 862 If multiple C<*> appear as terms within a single expression, the resulting
    841 closure binds them all to the same argument, so C<* * *> translates to
    863 closure binds them all to the same argument, so C<* * *> returns the closure
    842 864 C<{ $_ * $_ }>.
    843 865
    844 These closures are of type C<WhateverCode>, not C<Whatever>, so that constructs can distinguish
    845 via multiple dispatch:
    866 These returned closures are of type C<WhateverCode>, not C<Whatever>,
    867 so that constructs can distinguish via multiple dispatch:
    846 868
    847 869 1,2,3 ... *
    848 870 1,2,3 ... *+1
    … …  
    863 885
    864 886 The C<...> operator is instead dispatching bare C<*> to a routine that
    865 887 does dwimmery, and in this case decides to supply a function { * + 1 }.
    888 There is no requirement that an operator return a closure when C<Whatever>
    889 is used as an argument; that's just the I<typical> behavior for functions
    890 that have no intrinsic "globbish" meaning for C<*>.
    866 891
    867 892 The final element of an array is subscripted as C<@a[*-1]>,
    868 893 which means that when the subscripting operation discovers a C<WhateverCode>