Proposal: receiving arguments without enforcing context
Hi,
Captures are sensitive things, they can only be used "as-is" inside a
scalar, otherwise you have to enforce a context and it is no longer a
capture, but one of the views of its content.
for instance...
sub foo {
...
return @thingy, :named($value);
}
sub bar($capture) {
my $named := |$capture;
my @things := |$capture;
...
}
bar(foo());
The problem with the above code, is that the :($capture) signature,
already enforces item context, and therefore the two statements in sub
bar will simply fail.
That being said, I'd like to suggest a new syntax:
sub bar(\$capture) {
...
}
This syntax will mean that you want that positional argument without
forcing any context. This is something different from
sub bar(|$capture) {
...
}
which takes the entire capture sent to that invocation and store in the
variable, the proposed syntax would allow:
sub foo {
return 1,2,3;
}
sub bar(\$capture, $other) {
...;
}
bar(foo(), "somethingelse");
This need came out because of
method postcircumfix:<( )>($capture)
we need to receive the positional argument for .() without forcing the
context. I understand this method used to have a (|$capture) signature,
and it was changed by a request I made, but I'd like to remember that (|
$capture) and (\$capture) are completely different things, and SMOP
already takes advantage on that, the current signature for .() in SMOP
is:
method postcircumfix:<( )>(\$capture, :$cc)
where $cc is there to support call with current contination (currently
used in exception handling).
The other method that requires such concept is
method dispatch($object, $identifier, \$capture) {...}
in ClassHOW, which will actually call postcircumfix:<( )> in the end, so
it needs the capture "as-is".
Aditionally to this syntax, one point requires attention. If
foo((a => 1));
makes the pair a positional argument, it's natural that
foo((|$capture));
makes the capture a positional argument, instead of expanding it into
the argument list, and thus closing the loop in "how to use a capture
object" ;)
daniel
r24680 - docs/Perl6/Spec
Author: lwall
Date: 2008-12-29 18:16:02 +0100 (Mon, 29 Dec 2008)
New Revision: 24680
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] derivatives of * are Code, not Whatever
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2008-12-29 16:31:58 UTC (rev 24679)
+++ docs/Perl6/Spec/S02-bits.pod2008-12-29 17:16:02 UTC (rev 24680)
@@ -12,9 +12,9 @@
Maintainer: Larry Wall
Date: 10 Aug 2004
- Last Modified: 27 Dec 2008
+ Last Modified: 29 Dec 2008
Number: 2
- Version: 145
+ Version: 146
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -809,15 +809,18 @@
* - 1
-produces a result similar to:
+produces a function of a single argument:
{ $^x - 1 }
-except that the result is still of type C.
+This closure is of type C, not C, so that constructs can
distinguish
+via multiple dispatch:
-A value of type C may therefore be called as a function of
-one argument. The bare C<*> form therefore represents the identify function:
+1,2,3 ... *
+1,2,3 ... *+1
+The bare C<*> form may also be called as a function, and represents the
identify function:
+
*(42) == 42
(* + 1)(42) == 43
r24681 - docs/Perl6/Spec
Author: schwarzer Date: 2008-12-29 22:41:59 +0100 (Mon, 29 Dec 2008) New Revision: 24681 Modified: docs/Perl6/Spec/S01-overview.pod Log: [docs/Perl6/Spec] typo: use lower case letters Modified: docs/Perl6/Spec/S01-overview.pod === --- docs/Perl6/Spec/S01-overview.pod2008-12-29 17:16:02 UTC (rev 24680) +++ docs/Perl6/Spec/S01-overview.pod2008-12-29 21:41:59 UTC (rev 24681) @@ -80,8 +80,8 @@ =item * RFCs are rated on "PSA": whether they point out a real Problem, -whether they present a viable Solution, and whether that solution is -likely to be Accepted as part of Perl 6. +whether they present a viable solution, and whether that solution is +likely to be accepted as part of Perl 6. =item *
r24682 - docs/Perl6/Spec
Author: schwarzer
Date: 2008-12-29 22:43:47 +0100 (Mon, 29 Dec 2008)
New Revision: 24682
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[docs/Perl6/Spec] typos and minor style changes
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2008-12-29 21:41:59 UTC (rev 24681)
+++ docs/Perl6/Spec/S03-operators.pod 2008-12-29 21:43:47 UTC (rev 24682)
@@ -2256,9 +2256,9 @@
The postfix interpretation of an operator may be overridden by
use of a quoted method call, which calls the prefix form instead.
So C is always the postfix operator, but C will always
-call C. In particular, you can say things like C<$array.'@'>.
-and C<$fh.'='>, which
-because of the quotes will not be confused lexically with C<$fh.=new>.
+call C. In particular, you can say things like C<$array.'@'>
+and C<$fh.'='>, which will not be confused lexically with C<$fh.=new>
+due to the quotes.
=item *
@@ -2302,8 +2302,8 @@
=item *
-C splits into two operators: C (which concatenates repetitions
-of a string to produce a single string), and C (which creates a list of
+C splits into two operators: C (which concatenates repetitions
+of a string to produce a single string), and C (which creates a list of
repetitions of a list or item). C<"foo" xx *> represents an arbitrary
number of copies, useful for initializing lists. The left side of
an C is evaluated only once. (To call a block repeatedly, use a C
@@ -2650,9 +2650,8 @@
(1|2|3) + 4;# 5|6|7
(1|2) + (3&4); # (4|5) & (5|6)
-Note how when two junctions are applied through an operator, the result
-is a junction representing the operator applied to each combination of
-values.
+Note how the result is a junction representing the operator applied to each
+combination of values, when two junctions are applied through an operator.
Junctions come with the functional variants C, C, C, and
C.
@@ -2771,7 +2770,7 @@
=item *
-The C operator (less than, equal, or greater) is defined
+The C operator (less than, equal or greater than) is defined
in terms of C, so C<$a leg $b> is now defined as C<~$a cmp ~$b>.
The sort operator still defaults to C rather than C. The
C<< <=> >> operator's semantics are unchanged except that it returns
@@ -2878,7 +2877,7 @@
@array[0...@array], @array[*-1] xx *
-An empty Range cannot be iterated; it returns a C instead. An empty
+An empty range cannot be iterated; it returns a C instead. An empty
range still has a defined min and max, but the min is greater than the max.
If a range is generated using a magical autoincrement, it stops if the magical
@@ -2927,7 +2926,7 @@
In particular, multiplicative operators not only multiply the endpoints
but also the "by" of the C object:
-(1..11:by(2)) * 5 # same as 5..55:by(10)
+(1..11:by(2)) * 5 # same as 5..55:by(10)
5,15,25,35,45,45,55
Conjecture: non-linear functions might even produce non-uniform "by" values!
@@ -3341,7 +3340,7 @@
<== grep { /^ \d+ $/ }
<== @data;
-Either form more clearly indicates the flow of data. See S06 for
+Either form more clearly indicates the flow of data. See S06 for
more of the (less-than-obvious) details on these two operators.
=head1 Meta operators
Apoclypse 04 - update hint update
In A04 the sub section RFC 022: Control flow: Builtin switch statement There's the table: Table 1: Matching a switch value against a case value and the remark at the end: [Update: This is inaccurate in several ways; see the most recent table in S04.] as best I can tell, the actual table is in S03, under Smart Matching. a --- Andy Bach Systems Mangler Internet: andy_b...@wiwb.uscourts.gov Voice: (608) 261-5738; Cell: (608) 658-1890 As long as war is regarded as wicked, it will always have its fascination. When it is looked upon as vulgar, it will cease to be popular.-- Oscar Wilde
