[svn:perl6-synopsis] r13592 - doc/trunk/design/syn
Author: larry Date: Tue Feb 20 09:35:53 2007 New Revision: 13592 Modified: doc/trunk/design/syn/S12.pod Log: Conjecturalized the delegation-via-hash syntax for now. Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podTue Feb 20 09:35:53 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 15 Feb 2007 + Last Modified: 20 Feb 2007 Number: 12 - Version: 41 + Version: 42 =head1 Overview @@ -1325,7 +1325,7 @@ not the declared type. Any other kind of argument to C is considered to be a -smartmatch selector for methods. So you can say: +smartmatch selector for method names. So you can say: has $.fur is rw handles /^get_/; @@ -1334,7 +1334,9 @@ has $.fur is rw handles Groomable; then you get only those methods available via the C role -or class. +or class. To delegate everything, use the C matcher: + +has $the_real_me handles *; Wildcard matches are evaluated only after it has been determined that there's no exact match to the method name anywhere. When you have @@ -1369,22 +1371,26 @@ This is not considered a wildcard match unless the "handles" argument forces it to be. -If your delegation object happens to be a hash: +[Conjectural: the hash syntax is reserved until we figure out the +semantics we really want, and whether this actually buys us anything +over normal polymorphism.] If your delegation object happens to be +a hash: has %objects handles 'foo'; -then the hash provides a mapping from the string value of "self" -to the object that should be delegated to: +then the hash provides a mapping from a set of Selectors specified as Pair +keys to the object specified as the Pair value that should be delegated to: has %barkers handles "bark" = (Chihauhau => $yip, Beagle => $yap, Terrier => $arf, StBernard => $woof, + * => $ruff, ); method prefix:<~>( return "$.breed" ) -If the string is not found in the hash, a "C" is +If the current object matches no Selector, a "C" is automatically performed. =head1 Types and Subtypes
Y not
I think the ¥ and Y operators are going to have to change to something else.
The current Y has at least four strikes against it:
* It's an ASCII version of a cute Unicode picture, but other than that,
the picture it doesn't remind you of "zip" at all, especially in
the Y form.
* Functional programmers are likely to continually confuse it with the
Y combinator, and they'll be confused enough as it is.
* It violates the item-vs-list meme that we acquired with x vs xx and
X vs XX.
* Huffmanly speaking, it's rather short for its weight.
Those last reasons suggest that we want something spelled with a double
letter like XX. I thought about replacing it with YY (and letting Y
be the string form of zip), but that looks even less like a zipper.
But I do like the double letter idea for infix listops. It helps them
stand out more. I suspect we'll have a lot of
for @foo XX @bar XX @baz -> $x, $y, $z {...}
as list comprehensions of cross operators, so you'd like to have something
similar for "zip" semantics, and I think the obvious thing is:
for @foo ZZ @bar ZZ @baz -> $x, $y, $z {...}
You'll note that this has association of using the same letter, but
for those who mourn the loss of the word picture, note that the two
Z's form a pair of parallel lines in the middle, indicating that zip
treats the arrays in parallel. Plus the Z itself can be taken to be
a picture of "row major" visitation order: "first you go across, then
go to the beginning of the next row, then go across again."
The Z operator would presumably be the equivalent of >>~<< except that,
as a list infix, it would take a list on either side rather than two
scalar objects as hyperops do.
One could go as far as to say that Z*Z is the list infix form of >>*<<.
Anyway, I think we're close to establishing a convention that a list
infix should generally be formed from two capital letters, with the
additional proviso that if the list infix promotes to a meta operator,
the base operator goes in the middle. And if there's a stringwise or
scalar form, it's the single letter.
'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-)
Larry
Re: Y not
On Tuesday 20 February 2007 12:42, Larry Wall wrote: > 'Course, if someone goes ahead and adds the Y combinator, one must > naturally begin to wonder what the YY combinator would be... :-) Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed existentialist solipsist operator. -- c
Re: Y not
Larry Wall schrieb: > I think the ¥ and Y operators are going to have to change to something else. Very probably I missed something as I'm only a distant observer of the Perl6 development: Why not just call it "zip"?! There is a function called zip, wouldn't it be possible to create an operator with the same name? zip(@a; @b) -> function @a zip @b -> operator Or would that lead to grammar ambiguities, that are impossible to resolve? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Y not
Thomas Wittek wrote:
Larry Wall schrieb:
> I think the ¥ and Y operators are going to have to change to something else.
Very probably I missed something as I'm only a distant observer of the
Perl6 development: Why not just call it "zip"?!
There is a function called zip, wouldn't it be possible to create an
operator with the same name?
zip(@a; @b) -> function
@a zip @b -> operator
Or would that lead to grammar ambiguities, that are impossible to resolve?
more generally, could we say that any function that has no parameters
other than a list - i.e., :(*@) - automatically gets a list-infix
operator form as well? e.g.:
my sub zip([EMAIL PROTECTED]) { ... }
could be called with
zip (@a; @b; @c)
or
@a zip @b zip @c
--
Jonathan "Dataweaver" Lang
Re: Y not
On Wed, Feb 21, 2007 at 12:49:20AM +0100, Thomas Wittek wrote: : Larry Wall schrieb: : > I think the ¥ and Y operators are going to have to change to something else. : : Very probably I missed something as I'm only a distant observer of the : Perl6 development: Why not just call it "zip"?! : There is a function called zip, wouldn't it be possible to create an : operator with the same name? : : zip(@a; @b) -> function : @a zip @b -> operator : : Or would that lead to grammar ambiguities, that are impossible to resolve? Hmm, but then what corresponds to XX? I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function Larry
Re: Y not
Larry Wall wrote: Hmm, but then what corresponds to XX? I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function But the X*X already has a meaning: * under the cross metaoperator. Maybe you could use DD instead (for dot product). Joe Gottman
Re: Y not
[Off-list] I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c -> zip operator ZZ(@a; @b; @c) -> zip function @a XX @b XX @c -> cross operator XX(@a; @b; @c) -> cross function @a X*X @b X*X @c -> cross product operator X*X(@a; @b; @c) -> cross product function @a MM @b MM @c -> minmax operator MM(@a; @b; @c) -> minmax function I'm not strongly opposed to this, unless they're the *only* forms of the functions. If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Damian
Re: Y not
On 21/02/07, Damian Conway <[EMAIL PROTECTED]> wrote: [Off-list] Apparently not. Just pretend I'm not here. ;-) Damian
Re: Y not
On Tue, Feb 20, 2007 at 08:50:07PM -0500, Joe Gottman wrote: : Larry Wall wrote: : >Hmm, but then what corresponds to XX? I'd be more inclined to go : >the other way and say that you can transform any list infix form to : >the corresponding function form: : > : >@a ZZ @b ZZ @c -> zip operator : >ZZ(@a; @b; @c) -> zip function : > : >@a XX @b XX @c -> cross operator : >XX(@a; @b; @c) -> cross function : > : >@a X*X @b X*X @c -> cross product operator : >X*X(@a; @b; @c) -> cross product function : > : >@a MM @b MM @c -> minmax operator : >MM(@a; @b; @c) -> minmax function : > : > : > : > : But the X*X already has a meaning: * under the cross metaoperator. : Maybe you could use DD instead (for dot product). Oh, sorry, I mean "cross product" in the literal cross-multiply sense, not in the mathematical sense of dot product. But yeah, this would also a way for mathematicians to add similar vector operators in a somewhat consistent naming style. 'Course, if they're going to go to that extreme they'll probably just use ⋅ or some such. Larry
Re: Y not
Damian Conway wrote: > I'd be more inclined to go > the other way and say that you can transform any list infix form to > the corresponding function form: > > @a ZZ @b ZZ @c -> zip operator > ZZ(@a; @b; @c) -> zip function > > @a XX @b XX @c -> cross operator > XX(@a; @b; @c) -> cross function > > @a X*X @b X*X @c -> cross product operator > X*X(@a; @b; @c) -> cross product function > > @a MM @b MM @c -> minmax operator > MM(@a; @b; @c) -> minmax function Can't you already do this, with square braces? @a XX @b XX @c [XX] (@a; @b; @c) etc? Or am I missing something about the reduction metaoperator? I'm not strongly opposed to this, unless they're the *only* forms of the functions. If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Hear, hear. I very much prefer 'zip' and 'minmax' to 'ZZ' and 'MM'. -- Jonathan "Dataweaver" Lang
