Perl6 Operator List, TAKE 4
Michael Lazzaro
Okay, take 4, with 'X' meaning xor, so you can see it in context. I
warn ya, I'm gonna keep doing this until there's a "Final" version, for
some value of "Final". ;-) Again, I'm wondering if we're going about
this wrong way -- perhaps we need to go to more effort to save ^ as
xor, and use something different for hypers, like h<+> or h[+] or `+ or
~+ or ~~+, etc?
(I'm just leaving some of the questionable ops in for now, it's easier
to take them out later than re-add them for the various iterations.)
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
+X - force to numeric context, complement
~ - force to string context
~X - force to string context, complement
. - method call on current topic
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
... - [maybe] same as ..Inf
other postfix operators:
() - (when operator is expected)
[] - array access
{} - hash access
magical whitespace modifier
_ - remove whitespace/newline
hyperoperators:
^ - as prefix to any unary/binary operator, "vectorizes" the
operator
binary operators:
+ - * / % ** x xx ~
+= -= *= /= %= **= x= xx= ~=
< > <= >= == != <=>
lt gt le ge eq ne cmp
&& || XX // - boolean operations
&&= ||= XX= //=
and or xor err
.& .| .X << >> - bitwise operations
.&= .|= .X= <<= >>= - [maybe charwise too]
~& ~| ~X ~< ~> - [maybe] charwise operations
~&= ~|= ~X= ~<= ~>=
?& ?| ?X - [maybe] C-like bool operations
?&= ?|= ?X= - (result is always just 1 or 0)
& | X - superpositional operations
&= |= X= - intersection, union, disjunction
! - [maybe]
all any one none
sum prod cat reduce
~~ !~ - smartmatch, perl5 =~, !~
like unlike - [maybe]
=> - pair creator
, - list creator
; - "greater comma", list-of-lists creator
: - adverbial
. - method call
.. - range
... - [maybe] range, exclusive of endpoint
= - assignment
:= - binding
::= - binding, but more so
trinary operator:
?? :: - if/else
parens, misc, and quotelike operators
()
[] - [when term is expected]
{} - [when term is expected]
m// - shorthand, "matches"
s/// - shorthand, "substitute"
tr/// - shorthand, "transliterate"
'...' "..." `...` /.../ << >>
q qq qx rx qw [qm?]
(+ qr ?)
<...> - readline
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other assorteds, identified
when possible:
-X - [op] filetest operators
temp - [op]
let - [op]
ref - [op]
defined - [op]
undef - [op]
undef - [term]
exists - [op]
delete - [op]
but - [op] val properties
${ } - [deref] dereference scalarref
@{ } - [deref]
%{ } - [deref]
&{ } - [deref]
... - [term] yada**3
Inf - [term]
Nan - [term]
is - [declar] var properties
-> - [declar] like 'sub'
hash - [declar] force hash context
explicit radix specifications for integers:
0123 - decimal
2:0110 - binary [also b:0110?]
8:123 - octal [also o:123?]
16:123 - hex [also h:123?]
256:192.168.1.0 - base 256
(...etc...)
other uncategorized:
my our - [declar]
map grep
sqrt log sin cos tan (etc...) - math
lc lcfirst uc ucfirst
int ord oct hex bin
MikeL
Austin Hastings
$accumulator += +X10;
Looks like hex arithmetic.
=Austin
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Brian Wheeler
> explicit radix specifications for integers:
> 0123 - decimal
> 2:0110 - binary [also b:0110?]
> 8:123 - octal [also o:123?]
> 16:123 - hex [also h:123?]
> 256:192.168.1.0 - base 256
> (...etc...)
>
I've got to admit that I've not paid alot of attention to this
thread...but does that mean 0x1234 and 01234 (octal) go away or is this
an omission?
Brian Wheeler
bdwh...@indiana.edu
Dan Sugalski
>On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote:
>
>> explicit radix specifications for integers:
>> 0123 - decimal
>> 2:0110 - binary [also b:0110?]
>> 8:123 - octal [also o:123?]
>> 16:123 - hex [also h:123?]
>> 256:192.168.1.0 - base 256
>> (...etc...)
>>
>
>I've got to admit that I've not paid alot of attention to this
>thread...but does that mean 0x1234 and 01234 (octal) go away or is this
>an omission?
While we're at it, maybe we can add in 0rMCM to allow roman numerals too...
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Mark J. Reed
> [The below is actually from Larry, not Michael]
> > explicit radix specifications for integers:
> > 0123 - decimal
> > 2:0110 - binary [also b:0110?]
> > 8:123 - octal [also o:123?]
> > 16:123 - hex [also h:123?]
> > 256:192.168.1.0 - base 256
> > (...etc...)
leading 0 meaning octal - which is counterintuitive to everyone the
first time they come across it in C or Perl or Java or wherever.
So yes, as indicated by the first line above, if
this proposal were to be adopted (and again, it's just Larry thinking out
loud), 0123 would be 123 decimal, not 123 octal = 83 decimal.
However I don't see any reason not to allow 0x as a synonym for
16: (or 16# or whatever the radix syntax would be).
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Dan Sugalski
>On 2002-10-28 at 16:39:10, brian wheeler wrote:
>> [The below is actually from Larry, not Michael]
>> > explicit radix specifications for integers:
>> > 0123 - decimal
>> > 2:0110 - binary [also b:0110?]
>> > 8:123 - octal [also o:123?]
>> > 16:123 - hex [also h:123?]
>> > 256:192.168.1.0 - base 256
>> > (...etc...)
>The post that started this thread was a complaint about
>leading 0 meaning octal - which is counterintuitive to everyone the
>first time they come across it in C or Perl or Java or wherever.
That's not entirely true. Granted the set of the people for whom a
leading 0 instinctively means octal is not that big (and getting
smaller due to retirement and death from old age :) but it was
meaningful at one time.
Austin Hastings
0X14 currently is an expression whose value is 14.
If we're going to kill the alternate radix literals, better to do
something like hex:123 or hex "123". I'd hate to try to comprehend
$a = -x:123;
more than a week from now. (Is it a negative hexadecimal number, or a
boolean representing file permissions, or something far more sinister?)
=Austin
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
Mark J. Reed
On 2002-10-28 at 16:54:26, Dan Sugalski wrote:
> >The post that started this thread was a complaint about
> >leading 0 meaning octal - which is counterintuitive to everyone the
> >first time they come across it in C or Perl or Java or wherever.
>
> That's not entirely true. Granted the set of the people for whom a
> leading 0 instinctively means octal is not that big (and getting
> smaller due to retirement and death from old age :) but it was
> meaningful at one time.
each of these supposed old codgers came across the leading 0 used
for octal - in whatever context in whatever decade that might have
been - it was counterintuitive, since it runs against what we're
taught in mathematics from grade school on. :)
Michael Lazzaro
> If we're going to kill the alternate radix literals, better to do
> something like hex:123 or hex "123". I'd hate to try to comprehend
> $a = -x:123;
> more than a week from now.
That x:123 part was my placeholder -- my bad, I forgot that was there
when I was copying it. Yes, I think more likely scenarios would be
0b0110 or bin:0110
0c0123 or oct:0123
0x0123 or hex:0123
And almost certainly the former, not the latter. I'll put 0b, 0c, 0x
for now (assuming we don't want 0o0123, which looks too, um, loopy.)
Dan Sugalski wrote:
> While we're at it, maybe we can add in 0rMCM to allow roman numerals
> too...
OK, see, the sad thing is that I really have no idea whether you're
joking or not. That's how wiggy this thread has gotten.
MikeL
Brian Wheeler
> On 2002-10-28 at 16:39:10, brian wheeler wrote:
> > [The below is actually from Larry, not Michael]
> > > explicit radix specifications for integers:
> > > 0123 - decimal
> > > 2:0110 - binary [also b:0110?]
> > > 8:123 - octal [also o:123?]
> > > 16:123 - hex [also h:123?]
> > > 256:192.168.1.0 - base 256
> > > (...etc...)
> The post that started this thread was a complaint about
> leading 0 meaning octal - which is counterintuitive to everyone the
> first time they come across it in C or Perl or Java or wherever.
> So yes, as indicated by the first line above, if
> this proposal were to be adopted (and again, it's just Larry thinking out
> loud), 0123 would be 123 decimal, not 123 octal = 83 decimal.
>
That's fair..especially since the only place most people use octal is
mkdir and chmod.
> However I don't see any reason not to allow 0x as a synonym for
> 16: (or 16# or whatever the radix syntax would be).
That's probably a good idea to make it a synonym since hex notation is
used much more often than octal.
Thanks for the clarification!
Brian
Mark J. Reed
> What about specifying endiannes also, or would that be too low-level
> to even consider? Currently I don't have any examples for where it
> might even be used...
Literals are the wrong place to put that; they represent values, not
storage. Endianness should generally not be visible at the language
level; were you need to specify it, it will usually be an attribute/property
of the data source you're reading from or the sink you're writing to.
Dan Sugalski
>Dan Sugalski wrote:
>>While we're at it, maybe we can add in 0rMCM to allow roman numerals too...
>
>OK, see, the sad thing is that I really have no idea whether you're
>joking or not. That's how wiggy this thread has gotten.
I am joking--it's definitely a bad sign that you can't tell. :-P
(Of course, I'm hardly one to talk, what with Parrot and all...)
Markus Laire
> At 4:39 PM -0500 10/28/02, brian wheeler wrote:
> >On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote:
> >
> >> explicit radix specifications for integers:
> >> 0123 - decimal
> >> 2:0110 - binary [also b:0110?]
> >> 8:123 - octal [also o:123?]
> >> 16:123 - hex [also h:123?]
> >> 256:192.168.1.0 - base 256
> >> (...etc...)
> >>
> >
> >I've got to admit that I've not paid alot of attention to this
> >thread...but does that mean 0x1234 and 01234 (octal) go away or is
> >this an omission?
>
> While we're at it, maybe we can add in 0rMCM to allow roman numerals
> too... --
What about specifying endiannes also, or would that be too low-level
to even consider? Currently I don't have any examples for where it
might even be used...
--
Markus Laire 'malaire' <markus...@nic.fi>
Austin Hastings
going to be an issue is the specifiers for pack/unpack or whatever
replaces them.
But the presence of the >>> operator (and speaking of low-frequency
operators, what about bitwise rotation? Will that be the (( and ))
operators?) means that signed/unsigned conversions need to be thought
out.
Is 0xDEADBEEF >>> 3 going to be positive or negative?
=Austin
Dan Sugalski
Nope, not a problem. Roman Numerals are big-endian by definition.
Larry Wall
: But the presence of the >>> operator
Er, *what* >>> operator?
: (and speaking of low-frequency operators, what about bitwise rotation?
: Will that be the (( and )) operators?)
I think those will be rejected by anyone who uses either vi or emacs.
Seriously, let's not make the $( and $) mistake again.
: means that signed/unsigned conversions need to be thought out.
:
: Is 0xDEADBEEF >>> 3 going to be positive or negative?
Depends on whether you're a vegetarian. Personally I consider it
to be a positive. Perl 5 seems to concur.
Larry
Austin Hastings
shift?
If not, I apologize.
But on the other hand, we could make a ~>>> operator that was a
"case-preserving indent" :-)
=Austin
Richard Nuttall
>
> explicit radix specifications for integers:
> 0123 - decimal
> 2:0110 - binary [also b:0110?]
> 8:123 - octal [also o:123?]
> 16:123 - hex [also h:123?]
> 256:192.168.1.0 - base 256
> (...etc...)
>
strings, rather than using pack/unpack/sprintf, etc. ?
my $macaddr = '00022D3F7659';
my $hex = 16:$macaddr;
How about
$a = 'DEADBEEF';
$hexres = 16:$a + 16:FEED;
print ~16:$hexres;
does that give me "DEAEBDDC" ?
R.
--
Richard Nuttall
Michael Lazzaro
On Monday, October 28, 2002, at 01:25 PM, Michael Lazzaro wrote:
> Again, I'm wondering if we're going about this wrong way -- perhaps we
> need to go to more effort to save ^ as xor, and use something
> different for hypers, like h<+> or h[+] or `+ or ~+ or ~~+, etc?
OK, I'm calling "Warnock's" on this one. Is this just so far-fetched
that nobody's touching it with a ten foot pole, or am I missing
something, or ?
I know this was dealt with many months ago, but that was before we
changed ~ to stringify, making the xor situation worse. Isn't there
any way to keep ^, since we've just stated that the super meaning "one"
($a ^ $b ^ $c) is actually a worthwhile concept? (Yes, we would also
need to think about altering { $^a op $^b } in the same way.)
I'll shut up now on this one. But nobody's taking the bait, eh?
MikeL
Damian Conway
Hate it, hate it, hate it! Yuck, yuck, yuck!
But I do like Michael's idea of using C<@> as the hyperoperator marker
(the array connotation works well, I think). The only problem is that
we end up with too many C<@>'s in most expressions:
$count = @a + @b;
@sums = @a @+ @b;
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
I also think that binary C<!> as a none-ary superposition compositor is
a mistake. And that C<!!> and C<nor> would be even bigger ones. That's
because something like:
if $x ! $y ! $z { ... }
or:
if $x !! $y !! $z { ... }
is surreptitiously negative. Specifically, it's that missing "neither"
in from of the first operand that niggles. I'd much rather people had
to write one of these:
if !($x || $y || $z) { ... }
unless $x || $y || $z { ... }
With that in mind, by freeing up C<^> to resume its original xorish duties,
we get:
unary (prefix) operators:
! - force to bool context, negate
~ - force to string context
+^ - force to numeric context, complement
~^ - force to string context, complement
hyperoperators:
[op] - around any unary/binary operator, "vectorizes" the operator
binary operators:
~ - string concatenation
~= - string append
&& || ^^ // - boolean operations
&&= ||= ^^= //=
and or xor err
+& +| +^ << >> - bitwise operations
+&= +|= +^= <<= >>=
~& ~| ~^ - charwise operations
~&= ~|= ~^=
?& ?| ?^ - [maybe] C-like bool operations
?&= ?|= ?^= - (result is always just 1 or 0)
& | ^ - superpositional operations
&= |= ^= - conjunctive, disjunctive, exclusive
all any one none - conjunctive, disjunctive, exclusive, dismissive
~~ !~ - smart match, smart non-match
Damian
Uri Guttman
DC> Oh boy, I just *hate* the idea of C<X> for xor.
DC> Hate it, hate it, hate it! Yuck, yuck, yuck!
tell us how you _really_ feel! :-)
DC> My personal favorite solution is to use square brackets (for their dual
DC> array and indexing connotations, and because they highlight the operator
DC> so nicely):
DC> $count = @a + @b;
DC> @sums = @a [+] @b;
DC> [op] - around any unary/binary operator, "vectorizes" the operator
that is actually very neat IMO. it does read well and makes sense too.
DC> unary (prefix) operators:
DC> ! - force to bool context, negate
DC> ~ - force to string context
DC> +^ - force to numeric context, complement
DC> ~^ - force to string context, complement
what is a string complement? bitwise? i take it the numeric is one's
complement.
DC> binary operators:
DC> ~ - string concatenation
DC> ~= - string append
what happens to _?
DC> && || ^^ // - boolean operations
DC> &&= ||= ^^= //=
DC> and or xor err
DC> +& +| +^ << >> - bitwise operations
DC> +&= +|= +^= <<= >>=
i would add the word integer there. they do bitwise math on the integer
part of a scalar value.
DC> ~& ~| ~^ - charwise operations
DC> ~&= ~|= ~^=
and these do bitwise operations but on the string part of a
scalar. charwise isn't the best name for that.
DC> ?& ?| ?^ - [maybe] C-like bool operations
DC> ?&= ?|= ?^= - (result is always just 1 or 0)
hmm.
DC> ~~ !~ - smart match, smart non-match
is that also bind for tr///?
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Michael Lazzaro
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
> My personal favorite solution is to use square brackets (for their dual
> array and indexing connotations, and because they highlight the
> operator
> so nicely):
>
> $count = @a + @b;
> @sums = @a [+] @b;
Any ideas on what
{ $^a op $^b }
would become?
MikeL
Damian Conway
> Any ideas on what
>
> { $^a op $^b }
>
> would become?
It would be unchanged. Placeholders have nothing to do with hyperoperators.
And never have had.
Damian
Luke Palmer
> Date: Tue, 29 Oct 2002 11:36:20 -0800
> Cc: perl6-l...@perl.org
> From: Michael Lazzaro <mlaz...@cognitivity.com>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Hmm... I was thinking something along the lines of:
{ $^a op $^b }
[i.e. this change doesn't make any difference]
Luke
Damian Conway
> what is a string complement? bitwise? i take it the numeric is one's
> complement.
String complement treats the value as a string then bitwise complements every
bit of each character.
Integer complement treats the value as a int then bitwise complements every
bit.
> DC> ~ - string concatenation
> DC> ~= - string append
>
> what happens to _?
Someone hasn't been playing along at home! ;-)
We're contemplating reshuffling the ops to eliminate it.
> DC> +& +| +^ << >> - bitwise operations
> DC> +&= +|= +^= <<= >>=
>
> i would add the word integer there. they do bitwise math on the integer
> part of a scalar value.
Good point. Thanks.
> DC> ~~ !~ - smart match, smart non-match
>
> is that also bind for tr///?
That's still being discussed at the moment.
Damian
Michael Lazzaro
On Tuesday, October 29, 2002, at 11:47 AM, Luke Palmer wrote:
> [i.e. this change doesn't make any difference]
Doh! You're right, of course. For some reason I was thinking a long
while back that it would be confusing to have
{ $^a op $^b }
if ^ went back to meaning xor. But there's the sigils there, so never
mind. The problem was imaginary.
MikeL
Dave Mitchell
> String complement treats the value as a string then bitwise complements every
> bit of each character.
Is that the complement of the codepoint or the individual bytes?
(I'm thinking utf8 here).
--
Nothing ventured, nothing lost.
fear...@figaro.weizmann.ac.il
>
> Any ideas on what
>
> { $^a op $^b }
>
> would become?
>
> MikeL
maybe
{ $_a op $_b }
{ _ op _ }
and we have simple ( ? ) rules to distinguish it from "space-eater" _
* <sp > _ <sp> surrounded by spaces is placeholder if term is expected
* <sp> _postfixop "carriage-returns" and binds the operator to
previous term
* term_ <sp> eats to the next word but leaves zerowidth word boundary
* explicitely named placeholders in
{ $_a op $_b }
will have to begin with _ : $_a , $_b ( as before with ^ )
to remind that they are placeholders : named _ ;
I cannot quite see if that is totally consistent .
aracadi
Aaron Crane
> My personal favorite solution is to use square brackets (for their dual
> array and indexing connotations, and because they highlight the operator
> so nicely):
>
> $count = @a + @b;
> @sums = @a [+] @b;
Mmm, yummy. I do have a question though (and apologies if I've merely
missed the answer). We've got two productive operation-formation rules: one
saying "add a final = to operate-and-assign", and the other saying "wrap in
[] to vectorise". But no-one's said which order they apply in. That is,
which of these should I type:
@x [+]= @y;
@x [+=] @y;
Of course, the rule ordering didn't matter with the "add a leading ^ to
hype" rule.
I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Damian Conway
> Mmm, yummy. I do have a question though (and apologies if I've merely
> missed the answer). We've got two productive operation-formation rules: one
> saying "add a final = to operate-and-assign", and the other saying "wrap in
> [] to vectorise". But no-one's said which order they apply in. That is,
> which of these should I type:
>
> @x [+]= @y;
> @x [+=] @y;
>
> Of course, the rule ordering didn't matter with the "add a leading ^ to
> hype" rule.
>
> I think I prefer the first one, by the way -- it strikes me as more
> obviously a vector add.
Yep.
Damian
Luke Palmer
> From: Aaron Crane <aar...@gbdirect.co.uk>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Damian Conway writes:
> > My personal favorite solution is to use square brackets (for their dual
> > array and indexing connotations, and because they highlight the operator
> > so nicely):
> >
> > $count = @a + @b;
> > @sums = @a [+] @b;
>
> Mmm, yummy. I do have a question though (and apologies if I've merely
> missed the answer). We've got two productive operation-formation rules: one
> saying "add a final = to operate-and-assign", and the other saying "wrap in
> [] to vectorise". But no-one's said which order they apply in. That is,
> which of these should I type:
>
> @x [+]= @y;
> @x [+=] @y;
>
> Of course, the rule ordering didn't matter with the "add a leading ^ to
> hype" rule.
Hmm. Well, they're different:
@x [+]= @y;
@x = @x [+] @y;
@x [+=] @y;
for @x | @y -> $x is rw | $y {
$x += $y
}
:) Is there any advantage in differentiating that? Or would the
former *always* optimize to the latter?
Luke
Austin Hastings
@a [+=] @b;
implies iteratively invoking operator:+=, whereas
@a [+]= @b;
implies assigning the result of iteratively invoking operator:+
It only matters when they're different. :-|
And, of course, if they ARE different then the implication is that
signature-matching may also be involved, such that the version of
operator:+ (or +=) that gets used can change...
Hell, we might as well throw in multiple dispatch.
Any of you OO guys know of a case where
$a = $a + $b; # @A [+]= @B; --> @A = @A [+] @B;
and
$a += $b; # @A [+=] @B;
should be different? (Intuitively, I get the feeling that these cases
exist, especially in the weird cases kind of like the >> and <<
operators that C++ redefined for I/O. But I'm not sure if that's
paranoia causing me to accept lousy design, or what...)
Or should there be an overloadable operator:[op]= that takes arrays or
lists as its normal context? (Kind of like C++ differentiating between
new and new[])
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Simon Cozens
> (I'm thinking utf8 here).
I'd strongly advise against that.
--
Ermine? NO thanks. I take MINE black.
- Henry Braun is Oxford Zippy
Dan Sugalski
>da...@fdgroup.com (Dave Mitchell) writes:
>> (I'm thinking utf8 here).
>
>I'd strongly advise against that.
I'd agree. Thinking UTF-8 is generally a bad idea.
If you think anything, think fixed-size code points, since that's
what you're ultimately going to get. Probably 8 bit if you're ASCII,
Latin1, or EBCDIC, 16 if you're Shift-JIS or Big5 (either one), and
32 if you're dealing with Unicode.
It's possible you'll get UTF-8 (or UTF-16) but I think you'll be
hard-pressed to get there, at least without explicit hoop-jumping. I
certainly hope so, at least.
Larry Wall
: da...@fdgroup.com (Dave Mitchell) writes:
: > (I'm thinking utf8 here).
:
: I'd strongly advise against that.
Actually, it works out rather well in practice, because the string
abstraction in Perl is that of a sequence of codepoints. But at
least in Perl 5, as long as your codepoints don't get above 255,
it can still all be done with good old byte-ops.
Larry
David Whipp
> for @x | @y -> $x is rw | $y {
> $x += $y
> }
This superposition stuff is getting to me: I had a double-take,
wondering why we were iterating with superpositions (Bitops
never entered my mind). Did the C<;> ever officially change
to C<|> as the low-precidence list composer?
Dave.
ps. for readability, I think most situations require parenthesis
round these mega-lists.
Larry Wall
: Luke Palmer [mailto:fibo...@babylonia.flatirons.org] wrote:
:
: > for @x | @y -> $x is rw | $y {
: > $x += $y
: > }
:
: This superposition stuff is getting to me: I had a double-take,
: wondering why we were iterating with superpositions (Bitops
: never entered my mind). Did the C<;> ever officially change
: to C<|> as the low-precidence list composer?
No. It's still officially C<;>.
Larry
Dave Storrs
On Tue, 29 Oct 2002, Austin Hastings wrote:
> Hell, we might as well throw in multiple dispatch.
Actually, I am really hoping we do.
> Any of you OO guys know of a case where
>
> $a = $a + $b; # @A [+]= @B; --> @A = @A [+] @B;
>
> and
>
> $a += $b; # @A [+=] @B;
>
> should be different?
Any time that evaluating $a produces a side effect--for example,
if $a is a tied variable implementing a counter and increments itself by
one every time its value is fetched. If it started with a value of 5,
then $a += 3 leaves it with a value of 8, but $a = $a + 3 leaves it with a
value of 9.
Dave Storrs
John Williams
> Any of you OO guys know of a case where
>
> $a = $a + $b; # @A [+]= @B; --> @A = @A [+] @B;
>
> and
>
> $a += $b; # @A [+=] @B;
>
> should be different?
They are different in the "scalar [op] list" case, as explained here:
<http://archive.develooper.com/perl6-language%40perl.org/msg10961.html>
($a = 0) [+=] @b; # sum
($a = 1) [*=] @b; # product
($a ='') [~=] @b; # cat
~ John Williams
Larry Wall
: They are different in the "scalar [op] list" case, as explained here:
: <http://archive.develooper.com/perl6-language%40perl.org/msg10961.html>
:
: ($a = 0) [+=] @b; # sum
: ($a = 1) [*=] @b; # product
: ($a ='') [~=] @b; # cat
That's almost a reduce. Pity you have to include a variable.
But since rvalues are illegal on the left side of an assignment, we
*could* go as far as to say that
0 [+=] @b; # sum
1 [*=] @b; # product
'' [~=] @b; # cat
dwim into reduce operators rather than being illegal.
Larry
Damian Conway
> That's almost a reduce. Pity you have to include a variable.
> But since rvalues are illegal on the left side of an assignment, we
> *could* go as far as to say that
>
> 0 [+=] @b; # sum
> 1 [*=] @b; # product
> '' [~=] @b; # cat
>
> dwim into reduce operators rather than being illegal.
ETOOCLEVERBYHALF, IMHO. ;-)
I'd much rather see these common reductions be predefined C<sum>,
C<product>, and C<cat> methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a C<reduce>:
my $countersequence = reduce {$^x-$^y}, @b
Damian
Larry Wall
: Larry wrote:
:
: > That's almost a reduce. Pity you have to include a variable.
: > But since rvalues are illegal on the left side of an assignment, we
: > *could* go as far as to say that
: >
: > 0 [+=] @b; # sum
: > 1 [*=] @b; # product
: > '' [~=] @b; # cat
: >
: > dwim into reduce operators rather than being illegal.
:
: ETOOCLEVERBYHALF, IMHO. ;-)
That's why I said "*could*". But I couldn't not say it. :-)
: I'd much rather see these common reductions be predefined C<sum>,
: C<product>, and C<cat> methods of Array, and the more obscure
: and bizarre reductions be explicitly marked with a C<reduce>:
:
: my $countersequence = reduce {$^x-$^y}, @b
I agree.
Larry