Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[svn:perl6-synopsis] r11969 - doc/trunk/design/syn

7 views
Skip to first unread message

la...@cvs.perl.org

unread,
Sep 12, 2006, 2:07:01 PM9/12/06
to perl6-l...@perl.org
Author: larry
Date: Tue Sep 12 11:07:01 2006
New Revision: 11969

Modified:
doc/trunk/design/syn/S03.pod

Log:
New X operator and metaoperator.


Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Tue Sep 12 11:07:01 2006
@@ -14,7 +14,7 @@
Date: 8 Mar 2004
Last Modified: 12 Sep 2006
Number: 3
- Version: 58
+ Version: 59

=head1 Changes to Perl 5 operators

@@ -639,7 +639,7 @@
operators yourself. Similarly, the carets that exclude the endpoints
on ranges are there by convention only.

-In contrast to that, Perl 6 has four standard metaoperators for
+In contrast to that, Perl 6 has five standard metaoperators for
turning a given existing operator into a related operator that is
more powerful (or at least differently powerful). These differ from a
mere naming convention in that Perl automatically generates these new
@@ -801,7 +801,7 @@

=head2 Reduction operators

-The final metaoperator in Perl 6 is the reduction operator. Any
+The fourth metaoperator in Perl 6 is the reduction operator. Any
infix operator (except for non-associating operators)
can be surrounded by square brackets in term position to
create a list operator that reduces using that operation:
@@ -1025,6 +1025,52 @@
mean the normal reduction of C<< infix:<\x> >> operator, not the triangular
reduction of C<< infix:<x> >>. This is deemed to be an insignificant problem.

+=head1 Cross operators
+
+The final metaoperator is the C<X> metaoperator. It applies the
+modified operator across all permutations of its list arguments. All
+C<X> operators are of list infix precedence, and are list associative.
+
+The bare form of C<X> is considered an operator in its own right.
+Saying:
+
+ <a b> X 1,2 X <x y>
+
+produces
+
+ ['a', 1, 'x'],
+ ['a', 1, 'y'],
+ ['a', 2, 'x'],
+ ['a', 2, 'y'],
+ ['b', 1, 'x'],
+ ['b', 1, 'y'],
+ ['b', 2, 'x'],
+ ['b', 2, 'y']
+
+The string concatenating form is:
+
+ <a b> X~ <1 2> # 'a1', 'a2', 'b1', 'b2'
+
+As a metaoperator, C<X~> operator desugars to something like:
+
+ [~]«( <a b> X <1 2> ) # 'a1', 'a2', 'b1', 'b2'
+
+Any existing, non-mutating infix operator may be used after the C<X>.
+
+ 1,2 X* 3,4 # 3,4,6,8
+
+(Note that C<< <== >> and C<< ==> >> are considered mutating, as well as
+all assignment operators.)
+
+If the underlying operator is non-associating, so is the metaoperator:
+
+ @a Xcmp @b Xcmp @c # ILLEGAL
+ @a Xeq @b Xeq @c # ok
+
+Unlike bare C<X>, the C<X,> form flattens much like C<[,]> does.
+
+ <a b> X, <1 2> # 'a', '1', 'a', '2', 'b', '1', 'b', '2'
+
=head1 Junctive operators

C<|>, C<&>, and C<^> are no longer bitwise operators (see
@@ -1401,6 +1447,18 @@

@foo := [[1,2,3],[4,5,6]]; say cat([;] @foo); # 1,2,3,4,5,6

+=head1 Crossing arrays
+
+In contrast to the zip operator, the C<X> operator returns all the
+permutations of its sublists. Hence you may say:
+
+ <a b> X <1 2>
+
+and you end up with
+
+ ['a', '1'], ['a', '2'], ['b', '1'], ['b', '2']
+
+It is really a variant of the C<X> metaoperator mentioned earlier.
=head1 Minimal whitespace DWIMmery

Whitespace is no longer allowed before the opening bracket of an array
@@ -1481,7 +1539,7 @@
!!! ... ???
[+] [*] [<] [,] [\+] [\*] etc.
(also = as list assignment)
- list infix ¥ <== ==>
+ list infix ¥ <== ==> X X~ X* Xeqv etc.
loose and and
loose or or xor err
expr terminator ; {} as control block, statement modifiers

Darren Duncan

unread,
Sep 13, 2006, 2:34:40 AM9/13/06
to perl6-l...@perl.org
At 11:07 AM -0700 9/12/06, la...@cvs.develooper.com wrote:
>+=head1 Cross operators
>+
>+The final metaoperator is the C<X> metaoperator. It applies the
>+modified operator across all permutations of its list arguments. All
>+C<X> operators are of list infix precedence, and are list associative.

AT LAST!

I remember raising the want of such an operator
on this list a year ago, but nothing really came
out of it. Specifically I mean the thread
"crossing lists" that I posted on 2005 Oct 27:

http://www.nntp.perl.org/group/perl.perl6.language/23878

But now I can update, for example, ext/Locale-KeyedText/ from this:

method get_set_member_combinations of Array of Str () {
return [@!member_names.map:{ @!set_names »~« $_ }];
}

To this:

method get_set_member_combinations of Array of Str () {
return [@!set_names X~ @!member_names];
}

So the code is now much more understandable as to what it does.

It should also help me to implement some aspects of Set::Relation, maybe.

Thank you for this update.

-- Darren Duncan

Miroslav Silovic

unread,
Sep 13, 2006, 5:12:41 AM9/13/06
to perl6-l...@perl.org
la...@cvs.perl.org wrote:
>
> +=head1 Cross operators
> +
> +The final metaoperator is the C<X> metaoperator. It applies the
> +modified operator across all permutations of its list arguments. All
> +C<X> operators are of list infix precedence, and are list associative.
> +
> +The bare form of C<X> is considered an operator in its own right.
> +Saying:
> +
> + <a b> X 1,2 X <x y>
> +
> +produces
> +
> + ['a', 1, 'x'],
> + ['a', 1, 'y'],
> + ['a', 2, 'x'],
> + ['a', 2, 'y'],
> + ['b', 1, 'x'],
> + ['b', 1, 'y'],
> + ['b', 2, 'x'],
> + ['b', 2, 'y']
>

Would it be possible to extend C<next> to pass its arguments to the
iterator being 'nexted'. Along with proper arguments to whichever lazy
object it generated by X, it'd enable this:

(where :$slice argument would cause X to increment the member of the
tuple at the appropriate index, and resets all the other ones):

for 1,2,3 X 1,2,3 -> [$i, $j] {
if $j > $i { next(slice => 0); }
say $i, $j;
}

11
21
22
31
32
33

As another example, if a tree iterator has :right keyword argument to
return the node to the right, you could do:

for $tree.each -> $node {
if $node.value > $goal { next; }
if $node.value < $goal {next :right; }
return $node;
}

Alternative proposal could be to allow expression after next, which gets
evaluated instead of incrementing the iterator, iterator is topic in
that expression and is replaced by the result.

So next True; causes infinite loop, next .left calls .left accessor and
next .right calls right accessor before reentering loop (but doesn't do
the default increment that for does).


0 new messages