Re: Perl6 Operator (REMAINING ISSUES)
Michael Lazarro wrote: > 1) Need a definite syntax for hypers >^[op] and <> > have been most seriously proposed -- something that keeps a > bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Reading the threads, it seems to have gotten lost in the shuffle. Ed
Re: Perl6 Operator (REMAINING ISSUES)
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Thu, 31 Oct 2002 11:13:28 -0800 > From: Ed Peschko <[EMAIL PROTECTED]> > Content-Disposition: inline > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > Michael Lazarro wrote: > > > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Reading the threads, it seems to have > gotten lost in the shuffle. Xor needs it. I'd place hypers in front of xor on my importance list, but that's just me. > Ed >
Re: Perl6 Operator (REMAINING ISSUES)
> > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). Personally, I liked the use of single backtick someone suggested. I suspect that this is because it seemed to be just as good as square brackets at getting out of the way visually (vastly better than ^); was enough to catch my attention to suggest something special was going on; was just one, unshifted, character (or two, if used for a `op`= variant); and seemed to be the least disruptive (it left ^ for other duties and just meant one needed to eliminate `` for a syscall; hmm, maybe that's not acceptable...) -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
On Thu, Oct 31, 2002 at 01:36:20PM -0600, Me wrote: > > > 1) Need a definite syntax for hypers > > > ^[op] and <> > > > have been most seriously proposed -- something that keeps a > > > bracketed syntax, but solves ambiguity issues. > > > > hm. What was wrong with just '^' again? > > Right. I didn't have a problem with ^ in the first place. > > But... > > A ^ prefix visually interferes a lot more with the op being > hypered. I didn't understand that until I first saw use of > square brackets (interestingly, use of angle brackets > didn't grab my attention, though that may have been > due to other factors). I know it clutters up things a bit, that's my very argument; that ^[ ] clutters up things even *more*. especially, with use of arrays: @array[1,2,3] ^[+=] @array[4,5,6]; bleah. @array[1,2,3] ^+= @array[4,5,6]; Not much of a improvement, but its palpable. There's some comfort knowing that '^' is being used as a sigil for an operator, and that all you need is one keystroke in order to use it. I guess it depends on how much hyperoperators are meant to be used. The more they are, the shorter the operator should be. Oh by the way. IMO 'vector' operators should be the proper term. Looking at the above sentence, the term 'hyperoperator' should be quietly euthanized. (or quickly shot.) Ed
Re: Perl6 Operator (REMAINING ISSUES)
> > A ^ prefix visually interferes a lot more > > I know it clutters up things a bit, that's my very argument; that > ^[ ] clutters up things even *more*. especially, with use of arrays: > > @array[1,2,3] ^[+=] @array[4,5,6]; > > bleah. > > @array[1,2,3] ^+= @array[4,5,6]; > > Not much of a improvement, but its palpable. Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: @a ^[+=] @b @a ^[+]= @b # vectorize the +, not the = @a ^+= @b @a ^+^= @b # vectorize the +, not the = ?!? > '^' is being used as a sigil for an operator, and that all > you need is one keystroke in order to use it. On my keyboard it's two (shift and the 6 key). > Oh by the way. IMO 'vector' operators should be the > proper term. Oops. Yes. -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
On Thursday, October 31, 2002, at 11:36 AM, Me wrote: A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). If we're talking about operators being "hypered," then I think that «op» makes a lot of sense. It reminds me of Perl 5's "spaceship" operator, <=>, and I think of a spaceship taking the operator and jumping into hyperspace. What could be a better analogy than that, quantumly speaking? Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl6 Operator (REMAINING ISSUES)
On 2002-10-31 at 12:45:23, David Wheeler wrote: > Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Well, the angle quotes happen to fall within Latin-1, and so they're easier to get to. On Windows you can either set up special key mappings or just type ALT+171 for « and ALT+187 for », which gets wearisome after a while although you can get your fingers taught pretty quickly. Vim and emacs and XIM all take care of the UNIX case. Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Presumably, though, if Perl did have Unicode operators, it would also have an ASCII alternative, even if only something like \u00ab and \u00bb. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perl6 Operator (REMAINING ISSUES)
> Maybe. I slightly prefer the first line right now. > But it's close, and I think I've gotten too used to > both notations to know what I'd think if I saw one > or other for the first time, and I don't know what > I'd think after a month of use of one or other. As > I said, it's close. This will defintely be my last > email on the topic... likewise.. > > There's a couple other reasons to go for ^[op]. > > One is that [] is more obviously indicative to a > newbie that there is some array aspect to how > the op applies than ^ (or backtick) would be. I think that this advantage pales to the cost of having to type three characters every single time someone has to use a vector operation. Its just as easy for a newbie to say 'aha! ^ means array!'. > Another is that bracketing works better to indicate > the difference between the two ...= variants that > might be useful: > > @a ^[+=] @b > @a ^[+]= @b # vectorize the +, not the = > > @a ^+= @b > @a ^+^= @b # vectorize the +, not the = ?!? > Ok, I can sort of see this, but what the #%@@$ do both of these things mean? I can see @a ^+= @b meaining $a[0] += $b[0] $a[0] += $b[1] $a[0] += $b[2] $a[0] += $b[3]...etc but @a ^[+]= @b?? I swear, this whole vector operator thing would be a lot easier to understand if everything was vectored or not, ie: @a = @b ^+ @c; was a syntax error or was optimised to: @a ^= @b ^+ @c; In that case, ^[+]= doesn't really make sense. Ed
Re: Perl6 Operator (REMAINING ISSUES)
Me writes:
> > > A ^ prefix visually interferes a lot more
> >
> > I know it clutters up things a bit, that's my very argument; that
> > ^[ ] clutters up things even *more*. especially, with use of arrays:
> >
> > @array[1,2,3] ^[+=] @array[4,5,6];
> >
> > bleah.
> >
> > @array[1,2,3] ^+= @array[4,5,6];
> >
> > Not much of a improvement, but its palpable.
>
> Maybe. I slightly prefer the first line right now.
> But it's close, and I think I've gotten too used to
> both notations to know what I'd think if I saw one
> or other for the first time, and I don't know what
> I'd think after a month of use of one or other. As
> I said, it's close. This will defintely be my last
> email on the topic...
>
actually , ones we decide that ^ *is necessary for vectorization , we
can allow other brackets , optional brackets ( where unambiguous ) ,
and spaces inside the brackets :
@a ^+= @b
@a ^[+]= @b
@a ^(+)= @b
@a ^( + )= @b
@a ^{ + }= @b
@a ^{+}= @b
@a ^[ + ]= @b
all that can *coexist* !
> There's a couple other reasons to go for ^[op].
>
> One is that [] is more obviously indicative to a
> newbie that there is some array aspect to how
> the op applies than ^ (or backtick) would be.
>
> Another is that bracketing works better to indicate
> the difference between the two ...= variants that
> might be useful:
>
> @a ^[+=] @b
> @a ^[+]= @b # vectorize the +, not the =
>
> @a ^+= @b
> @a ^+^= @b # vectorize the +, not the = ?!?
>
>
> > '^' is being used as a sigil for an operator, and that all
> > you need is one keystroke in order to use it.
>
> On my keyboard it's two (shift and the 6 key).
>
>
> > Oh by the way. IMO 'vector' operators should be the
> > proper term.
>
> Oops. Yes.
>
> --
> ralph
>
>
Re: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 15:59, Mark J. Reed wrote: > Once you wander away from Latin-1 into the more general world > of Unicode, you start running into trouble on the input side. > On Windows you pretty much have to use the Character map accessory. > Emacs and vim still work on UNIX, but I don't know of a XIM > implementation for general Unicode. (Although if you log into your > Unix machine using Kermit-95, it has a keystroke sequence for > arbitrary Unicode input). Emacs and vim also works on Windows, not just UNIX. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
RE: Perl6 Operator (REMAINING ISSUES)
Markus Laire:
# Emacs and vim also works on Windows, not just UNIX.
So does DOS 'edit'. That doesn't mean Windows users use it. Windows
users want tools that look and act like Windows tools--if they didn't,
they'd be using another OS. Neither GNU emacs nor xemacs fits the bill,
and I doubt vim does either.
I'm an aberration--I use Windows, but I have a Cygwin toolkit installed
and use it regularly. Still, I use VS.Net (with Visual Perl) for my
editing, not a Unix editor. When telnetting, I use emacs, so I
installed XEmacs, used it for a while, and decided I didn't like it for
my local work. It had some really cool features--I was *very*
pleasantly surprised at how nicely it meshed with CVS--but it just
didn't fit my Windows-shaped brain.
You can bet that if I, a Perl core hacker who keeps two copies of
cmd.exe open at all times with c:\cygwin\bin in his path, am not going
to use XEmacs, your average Joe who downloads ActiveState Perl 6 to test
his hit-counter script won't use emacs or vim either.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Perl6 Operator (REMAINING ISSUES)
> actually , ones we decide that ^ *is necessary for vectorization , we
> can allow other brackets , optional brackets ( where unambiguous ) ,
> and spaces inside the brackets :
>
> @a ^+= @b
> @a ^[+]= @b
> @a ^(+)= @b
> @a ^( + )= @b
> @a ^{ + }= @b
> @a ^{+}= @b
> @a ^[ + ]= @b
>
right, and what does this all mean? I have yet to see a good meaning for
@array ^[+]= @array2 ...
Perhaps, having just ^ as a vector op, and using ^[op] to disambiguate (or
as an equivalent) is the way to go.
Ed
Re: Perl6 Operator (REMAINING ISSUES)
On Thu, 31 Oct 2002, Ed Peschko wrote: > Michael Lazarro wrote: > > > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Reading the threads, it seems to have > gotten lost in the shuffle. Personally, I would like to see us come full circle back to just ^ again too. The main problem seems to be that we want ^ and ^^ for xor-ing things, so ^^ could be either a logical-xor or a vector-one-superposition. So what if we just made the [] optional? Then all the original hyper/vector documentation is still valid. (The meanings of ^+ ^|| ^<<= etc are all non-ambiguous.) For the ambiguous case, ^^ is logical-xor because it is used more often, and vector-one-superposition is unambiguously ^[^] . ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
y> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Fri, 1 Nov 2002 10:39:59 -0700 (MST) > From: John Williams <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > X-OriginalArrivalTime: 01 Nov 2002 17:40:00.0029 (UTC) FILETIME=[B38AC4D0:01C281CD] > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > On Thu, 31 Oct 2002, Ed Peschko wrote: > > > Michael Lazarro wrote: > > > > > 1) Need a definite syntax for hypers > > >^[op] and <> > > > have been most seriously proposed -- something that keeps a > > > bracketed syntax, but solves ambiguity issues. > > > > hm. What was wrong with just '^' again? Reading the threads, it seems to have > > gotten lost in the shuffle. > > Personally, I would like to see us come full circle back to just ^ again > too. > > The main problem seems to be that we want ^ and ^^ for xor-ing things, > so ^^ could be either a logical-xor or a vector-one-superposition. > > So what if we just made the [] optional? Then all the original > hyper/vector documentation is still valid. (The meanings of ^+ ^|| ^<<= > etc are all non-ambiguous.) For the ambiguous case, ^^ is logical-xor > because it is used more often, and vector-one-superposition is > unambiguously ^[^] . You know, I like it. In any "potentially ambiguous" cases, the non-vector version would be preferred. It doesn't seem exactly "elegant," but there's some appeal that I'm drawn to. Luke
Re: Perl6 Operator (REMAINING ISSUES)
> > right, and what does this all mean? I have yet to see a good meaning > > for > > @array ^[+]= @array2 ... > > I think it's this: > > @a [+=] @b -> @a[x] += @b[x] > > @a [+]= @b -> @temp = @a [+] @b; a = @temp; > Ok, so the '=' isn't being explicitly vectorized. So - @a ^[+]= @b; @a = (1,2,3,4); @b = (5,6,7,8); @temp = @a ^+ @b; = (1+5,2+6,3+7,4+8) = (6,8,10,12); @temp = (6,8,10,12); @a = (6,8,10,12); wheras: @a ^+= @b; $a[0] += $b[0]; $a[1] += $b[1]; $a[2] += $b[2]; $a[3] += $b[3]; $a[0] = 1 + 5; $a[1] = 2 + 6; $a[2] = 3 + 7; $a[3] = 4 + 8; @a = (6,8,10,12); ie: they are exactly the same. I'd say that '=' has *implicit* vectorization here in the array case. In the scalar case: @a ^[+]= 1; @temp = @a ^+ 1; it is exactly the same. @a ^+= 1; $a[0] +=1; $a[3] +=; So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms as far as I can see, and hence no need for the first form. Ed
Re: Perl6 Operator (REMAINING ISSUES)
Ed Peschko writes: > > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > as far as I can see, and hence no need for the first form. > > Ed > > > somebody before ( dont remember who) showed how they can be different if the first argument is scalar. arcadi .
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, 1 Nov 2002, Ed Peschko wrote: > @a ^[+]= @b; compared to > @a ^+= @b; > > ie: they are exactly the same. You are right, you get the same answer whether you do the hyper or the assignment first, except in the "scalar ^op= list", in which case doing the assignment last gets you the length of the list or some other useless result. > I'd say that '=' has *implicit* vectorization > here in the array case. In the scalar case: Right. ^= is rather pointless, because = already understands list context. OTOH, you can get some different effects out of ^= by virtue of the "dimensionally replicate, quantitatively undef-extend" rule for vectoring operators. @a ^= @b # @a.length == max( @a.length, @b.length ) @a ^= $b # all currently existing elements of @a are set to $b $b ^= @a # Yuck! $b = last element of @a. ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
--- Ed Peschko <[EMAIL PROTECTED]> wrote: > > > right, and what does this all mean? I have yet to see a good > meaning > > > for > > > @array ^[+]= @array2 ... > > > > I think it's this: > > > > @a [+=] @b -> @a[x] += @b[x] > > > > @a [+]= @b -> @temp = @a [+] @b; a = @temp; > > > > Ok, so the '=' isn't being explicitly vectorized. So - > > @a ^[+]= @b; > > @a = (1,2,3,4); @b = (5,6,7,8); > > @temp = @a ^+ @b; = (1+5,2+6,3+7,4+8) = (6,8,10,12); > > @temp = (6,8,10,12); > > @a = (6,8,10,12); > > > wheras: > > @a ^+= @b; > > $a[0] += $b[0]; > $a[1] += $b[1]; > $a[2] += $b[2]; > $a[3] += $b[3]; > > $a[0] = 1 + 5; > $a[1] = 2 + 6; > $a[2] = 3 + 7; > $a[3] = 4 + 8; > > @a = (6,8,10,12); > > ie: they are exactly the same. I'd say that '=' has *implicit* > vectorization > here in the array case. Ed, Under normal definitions, you're right. But under overload, you're seeing two different sets of operators get invoked? @temp = @a [+] @b; @a = @temp; This invokes N iterations of (multidispatch(operator:+, $a[n], $b[n])), which likely results in: N x Some_Class.new N x Underlying_type.operator:+($a[n], $b[n]) N x Some_Class.operator:= followed by one invocation of @a.operator=. Potentially useful if objects should be "rebalanced" or "snapshot" or "transactionalized" or something whenever a vector operation happens. Especially where variables are tied, or represent fanciful classes with simplified interfaces, this will be significant. OTOH: @a [+=] @b This invokes N iterations of (multidispatch(operator:+=, $a[n], $b[n])) which likely results in (if it doesn't actually IMPLEMENT): N x Underlying_type.operator:+ N x Some_Class.operator:= and nothing else. So there's no "initialize the temp object" or "close down the original @a TIE" or "whatever" getting invoked. And that can be a win, database-session-closeout-wise, or whatever your TIE'ing application happens to be. =Austin __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote: > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > as far as I can see, and hence no need for the first form. Only in the absence of overloading, and only because we've naively defined array ops to always do "union" rather than "intersection". If there were a vector op that took the shorter of two arrays as the overall length, then @a = @a »op« @b will truncate @a, while @a »op=« @b might only change the elements they have in common. I don't know if we'll have any such operators on arrays, but they've already been proposed for hashes. So %a »op=« %b might well be different from %a »op«= %b depending on what op is. Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote: > Right. ^= is rather pointless, because = already understands list > context. They're not quite the same because list assignment truncates first. To wit: @a = [1,2,3]; @b = [4,5]; @a = @b;# @a gets [4,5] @a ^= @b; # @a gets [4,5,undef] And if you define = as an "intersection" rather than a "union" op, you'd get @a ^= @b; # @a gets [4,5,3] Maybe. Or there could be a truncation implicit in intersection operators. > OTOH, you can get some different effects out of ^= by virtue of the > "dimensionally replicate, quantitatively undef-extend" rule for vectoring > operators. > >@a ^= @b # @a.length == max( @a.length, @b.length ) >@a ^= $b # all currently existing elements of @a are set to $b >$b ^= @a # Yuck! $b = last element of @a. Every possible utterance doesn't have to make practical sense... Larry
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, 1 Nov 2002, it was written: > On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote: > > So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms > > as far as I can see, and hence no need for the first form. > > Only in the absence of overloading, and only because we've naively > defined array ops to always do "union" rather than "intersection". > If there were a vector op that took the shorter of two arrays as the > overall length, then > > @a = @a »op« @b Ooo! I have it! @a »op« @b # picks the shorter of the two lengths (intersection) @a «op» @b # picks the longer of the two lengths (union) Maybe the hyper-hash guys could work with it too. ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
>> So again, I don't see the difference between the two. ^[+]= and ^+= are >> synonyms as far as I can see, and hence no need for the first form. > Only in the absence of overloading, and only because we've naively defined > array ops to always do "union" rather than "intersection". If there were a > vector op that took the shorter of two arrays as the overall length, then > > @a = @a »op« @b > > will truncate @a, while > > @a »op=« @b > > might only change the elements they have in common. I don't know if we'll > have any such operators on arrays, but they've already been proposed for > hashes. argh. you're scaring me just mentioning '»' and '«' as vector ops (ascii please!). Also, just mentioning array versus intersection scares me. You could make a case that: @a ^+= @b; does a truncate on @a if @b is shorter, and that @a v+= @b; is the 'true' union operator. You could hence argue that there are really two vector operators one for union and one for intersection, and that the place to define whether or not something as intersection or union belongs there, and not in the operator itself. Ed
RE: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 16:04, Brent Dax wrote: > Markus Laire: > # Emacs and vim also works on Windows, not just UNIX. > > So does DOS 'edit'. That doesn't mean Windows users use it. Windows > users want tools that look and act like Windows tools--if they didn't, > they'd be using another OS. Neither GNU emacs nor xemacs fits the > bill, and I doubt vim does either. gvim looks and acts a lot like usual Windows editors if you install it in proper 'windows compatible' mode. Still it is a bit different. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Perl6 Operator (REMAINING ISSUES)
to me , this discussion approaches the conclusion that
^[] and v[] are *just* another operators with their own behavior
that accept as ( optional ) argument a Code reference .
to follow the beautifull philosophy of perl6 -- "A is just B" we can
say ( following Larry Wall )
...
> A Perl5 magic is just a property.
> A Perl5 attribute is just a property.
> A block is just a closure.
> A control structure is just a subroutine that can call closures.
...
(maybe...)
A "for" loop is *almost* a subroutine that can call closures .
A vector operation is just a ( cryptographic ) "for" loop
with one or two input streams and name inside brackets
as a closure.
so it is just a function :
sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
my @inds = union( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}
sub infix:v[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
my @inds = intersection( @a.keys, @b.keys);
return for @inds {
&op ( @a[$_] , @b[$_] ) ;
}
}
or maybe
sub infix:^[] ( Code &op : Array @a , Array @b
) is parsed /^[ | \[\] ]/
{
return for @a ; @b -> ($x is rw ; $y is rw ) {
&op ( $x , $y ) ;
}
}
sub postfix:^[] ( Code &op : Array @a
) is parsed /^[ | \[\] ]/
{ for @a -> $x is rw &op( $x ) }
and analogous things for v[] . and this can be prefix, infix, postfix
; and each argument can be $a, @a, %a ; so it is a multimethod.
in that case the vectorization is *compleatly* orthogonal to the
details of op and we even can have something like
@a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b
arcadi
Re: Perl6 Operator (REMAINING ISSUES)
Larry Wall <> writes:
> On Fri, Nov 01, 2002 at 11:51:17AM -0700, John Williams wrote:
> > Right. ^= is rather pointless, because = already understands list
> > context.
>
> They're not quite the same because list assignment truncates first. To wit:
>
> @a = [1,2,3];
> @b = [4,5];
>
> @a = @b; # @a gets [4,5]
>
> @a ^= @b;# @a gets [4,5,undef]
>
> And if you define = as an "intersection" rather than a "union" op, you'd get
>
> @a ^= @b;# @a gets [4,5,3]
>
> Maybe. Or there could be a truncation implicit in intersection operators.
>
is it possible to make more clear this entry in the perl6 just-ice :
for loop is just ...
because it seems that all "plaintive wine" flows because that is
unclear .
because the second part seems to be obvious :
vector operation is just a "for" loop with arguments "scattered" around (
and inside) it .
something like
sub operator:^[] (Code &op, @a, @b) is parsed /\^\[\]/ { ... }
if we assume that ^[] staff is just a "for" loop ( that is, subroutine
) with one ( for prefix/postfix) or two ( for infix ) input streams (
wich can be degenerate if one of the arguments is scalar ) ( and ^[] is
more general , because it can accept hashes ( maybe we should allow
hash as input stream in "for" loop ) ) so if we assume that,
than probably the decision on union/intersection in vector ops and for
loop with multiple streams should be unifyed .
in for loop we have special "|" , "&" , stream separators to
distinguish/force what we want. why for vector operations this have to
be more implicit ? ( or may be I misunderstood and It is not ) .
in other words , is it going to be that each op will have its own
default behavior ( with respect to unify/intersect and such ) when
vectorized ? can I define an operator and be sure about its behavior
when vectorized , or should I specify it at scalar operator definition
, or should I define explicitely both scalar and vector version.
arcadi
Re: Perl6 Operator (REMAINING ISSUES)
On Sat, Nov 02, 2002 at 02:18:44AM +0200, [EMAIL PROTECTED] wrote:
>
snip ...
>
> in that case the vectorization is *compleatly* orthogonal to the
> details of op and we even can have something like
>
> @a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b
>
I agree with all that you said above, I'm just saying we should make typing []
*optional*. 99% of the time, people are not going to need it, as they are not
defining their own operators as you did above.
Ed
Re: Perl6 Operator (REMAINING ISSUES)
Ed Peschko writes: > I agree with all that you said above, I'm just saying we should make typing [] > *optional*. 99% of the time, people are not going to need it, as they are not > defining their own operators as you did above. > > Ed > > long ago ( when xor was "!" and ^ was called hyper ) Larry Wall was talking about allowing spaces between "bulding blocks of long operators @a ^ .+ = @b . so optional [ ] in vector operations becomes *very* similar to optional ( ) in function call . Now almost sure , that name of the vectorization will change couple of times ( and if it's sub one ( everyone will ! ) can define alias &operator:^[] := &operator:`<<>>` ( very vague ) ). so , maybe , the fruitfull way to generalize vector operations is to say : perl do not have vector operations . perl have operator algebra ( does it ? ) that can produce "vector" version of any operator , but more so . op op = ^ op v op t op ... arcadi
