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)
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: plaintive whine about 'for' syntax
Larry Wall writes:
> I think decent formatting would make it clearer:
>
> for@a; @b
> -> $x is rw; y {
>$x = $y[5];
> }
But this isn't very scalable:
for@a; @b;
@c; @d;
@e
-> $a_variable1 is rw, $a_variable2 is rw; $b_variable is rw;
$c_variable is rw; $d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
wheras:
for @a -> $a_variable1 is rw, $a_variable2 is rw;
@b -> $b_variable is rw;
@c -> $c_variable is rw;
@d -> $d_variable is rw;
@e -> $e_variable1 is rw, $e_variable2 is rw;
{
}
is much, *much* clearer. IMO the current 'for' syntax suffers from action at a
distance, even if that distance is within the same line. Related things aren't
paired up nearly close enough to each other.
And I'd curse it if I was writing 'for' expressions as complicated as the
second one. Which I WILL do, especially when writing code generators.
Ed
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)
> 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)
> > 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)
>> 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
vectorization (union and intersection operators)
I'm probably opening up a whole new can of worms here, but if we said that the
following were both vector operators:
^ == intersection operator
v == union operator
then these could have potentially useful meanings on their *own* as set
operators, as well as modifying other operators. For example:
@a = (1,2,3);
@b = (4,1,3);
@a = @a ^ @b; # @a = (1,3);
@a = @a v @b; # @a = (1,2,3,4);
ie @a = @a ^ @b; means
grep($MARK{$_}++, @a);
for @b { push (@result, $_) if ($MARK{$_} && !$MARK2{$_}++); }
@a = @result;
@a = @a v @b; means
grep( $MARK{$_}++, @a );
@result= @a;
for @b { push (@result, $_) if (!$MARK{$_}++) }
I know that this is far more useful behavior than the currently proposed meaning
of @a ^= @b... even though if its a little off kilter with the other meanings:
@a = (1,2,3);
@b = (4,1,3,5);
@a ^+= @b; # (5,3,6);
@a v+= @b; # (5,3,6,5);
etc. etc.
Ed
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: vectorization (union and intersection operators)
> I'm probably opening up a whole new can of worms here, but if we said > that the following were both vector operators: > > ^ == intersection operator > v == union operator > > then these could have potentially useful meanings on their *own* as set > operators, as well as modifying other operators. For example: > > @a = (1,2,3); > @b = (4,1,3); > > @a = @a ^ @b; # @a = (1,3); > @a = @a v @b; # @a = (1,2,3,4); Or is @a = (1,2,3,4,1,3) ? No... I'm assuming two things: 1) that v (union) uniqifies the elements in its array, as does ^. 2) that the v (union) modifier includes elements that exist in either the first set or the second set, and that ^ includes elements that exist in both sets. These are pragmatic operators; I've done this type of thing *exceedingly* often. The behaviour you describe is the concatenation of the two sets. I can get that for free by saying push(@a, @b), or @a = (@a, @b); And since admittedly they are pragmatic, people are welcome to overload them. But right now as it stands '@a v= @b' is nonsense; it might as well be put to work. Ed ( ps - as an aside, are the apocalypses going to be backdated as changes to the design come up? Or are the apocalypses just a first draft for more enduring documentation? )
