@@ -13,8 +13,8 @@ Synopsis 2: Bits and Pieces
13
13
14
14
Created: 10 Aug 2004
15
15
16
- Last Modified: 6 Oct 2011
17
- Version: 239
16
+ Last Modified: 7 Oct 2011
17
+ Version: 240
18
18
19
19
This document summarizes Apocalypse 2, which covers small-scale
20
20
lexical items and typological issues. (These Synopses also contain
@@ -1016,21 +1016,28 @@ by marking the proto sub with the trait, C<is like-Whatever-and-stuff>.
1016
1016
[Conjecture: actually, this is negotiable--we might shorten it
1017
1017
to C<is like(Whatever)> or some such. C<:-)>]
1018
1018
1019
- =head3 Priming of Unary and Binary Operators with Whatever
1019
+ =head3 Autopriming of Unary and Binary Operators with Whatever
1020
+
1021
+ Perl 6 has several ways of performing partial function application.
1022
+ Since this is an unwieldy term, we've settled on calling it I<priming>.
1023
+ (Many folks call this "currying", but that's not really a correct
1024
+ technical usage of the term.) Most generally, priming is performed
1025
+ on a C<Callable> object by calling its C<.assuming> method, described elsewhere.
1026
+ This section is about a convenient syntactic sugar for that.
1020
1027
1021
1028
For any unary or binary operator (specifically, any prefix, postfix,
1022
1029
and infix operator), if the operator has not specifically requested
1030
+ (via signature matching)
1023
1031
to handle C<*> itself, the compiler is required to translate directly
1024
- to an appropriately primed closure at compile time. (I<Priming> is our
1025
- term for partial function application. Many folks call this "currying", but
1026
- that's not really a correct technical usage of the term.) Most of the
1027
- built-in numeric operators fall into this category, so:
1032
+ to an appropriately primed closure at compile time. We call this
1033
+ I<autopriming>. Most of the built-in numeric operators fall into
1034
+ this category. So:
1028
1035
1029
1036
* - 1
1030
1037
'.' x *
1031
1038
* + *
1032
1039
1033
- are internally primed into closures of one or two arguments:
1040
+ are autoprimed into closures of one or two arguments:
1034
1041
1035
1042
{ $^x - 1 }
1036
1043
{ '.' x $^y }
@@ -1094,14 +1101,14 @@ far as it makes sense, including outward through metaoperators. Hence:
1094
1101
(-*.abs)i # { (-$^x.abs)i }
1095
1102
@a «+» * # { @a «+» $^x }
1096
1103
1097
- =head3 The C<.assuming> Method
1104
+ =head3 Operators with idiosyncratic Whatever
1098
1105
1099
- This is only for operators that are not C<Whatever>-aware. There is no requirement
1106
+ The above is only for operators that are not C<Whatever>-aware. There is no requirement
1100
1107
that a C<Whatever>-aware operator return a C<WhateverCode> when C<Whatever>
1101
1108
is used as an argument; that's just the I<typical> behavior for functions
1102
1109
that have no intrinsic "globbish" meaning for C<*>. If you want to prime
1103
1110
one of these globbish operators, you'll need to write an explicit closure or do
1104
- an explicit prime on the operator with C<.assuming()>. Operators in
1111
+ an explicit priming on the operator with C<.assuming()>. Operators in
1105
1112
this class, such as C<< infix:<..> >> and C<< infix:<xx> >>, typically I<do>
1106
1113
autoprime arguments of type C<WhateverCode> even though they do not
1107
1114
autoprime C<Whatever>, so we have:
@@ -2394,7 +2401,7 @@ Use of a signature that does not unambiguously select a single multi results in
2394
2401
failure.
2395
2402
2396
2403
It still just returns a C<Routine> object. A call may also be partially
2397
- applied by using the C<.assuming> method:
2404
+ applied (primed) by using the C<.assuming> method:
2398
2405
2399
2406
&foo.assuming(1,2,3,:mice<blind>)
2400
2407
0 commit comments