On Tue, 29 Oct 2002, Austin Hastings wrote:
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:
On Wed, 30 Oct 2002, John Williams wrote:
: 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
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
On Thu, 31 Oct 2002, Damian Conway wrote:
: 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
:
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
Oh boy, I just *hate* the idea of CX for xor.
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;
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 }
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Oh boy, I just *hate* the idea of CX 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
Michael Lazzaro wrote:
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
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 29 Oct 2002 11:36:20 -0800
Cc: [EMAIL PROTECTED]
From: Michael Lazzaro [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
My
Uri Guttman wrote:
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
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
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote:
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.
Michael Lazzaro writes:
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
Aaron Crane wrote:
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
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 29 Oct 2002 21:37:32 +
From: Aaron Crane [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Damian Conway writes:
My personal favorite solution is to use square
Interesting point, especially if operator:+= can be overloaded.
@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
[EMAIL PROTECTED] (Dave Mitchell) writes:
(I'm thinking utf8 here).
I'd strongly advise against that.
--
Ermine? NO thanks. I take MINE black.
- Henry Braun is Oxford Zippy
On 30 Oct 2002, Simon Cozens wrote:
: [EMAIL PROTECTED] (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,
At 1:20 AM + 10/30/02, Simon Cozens wrote:
[EMAIL PROTECTED] (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
Luke Palmer [mailto:fibonaci;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
On Tue, 29 Oct 2002, David Whipp wrote:
: Luke Palmer [mailto:fibonaci;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
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?
23 matches
Mail list logo
