Re: Perl6 Operator List, Damian's take
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: http://archive.develooper.com/perl6-language%40perl.org/msg10961.html ($a = 0) [+=] b; # sum ($a = 1) [*=] b; # product ($a ='') [~=] b; # cat ~ John Williams
Re: Perl6 Operator List, Damian's take
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 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
Re: Perl6 Operator List, Damian's take
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. ;-)
I'd much rather see these common reductions be predefined Csum,
Cproduct, and Ccat methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a Creduce:
my $countersequence = reduce {$^x-$^y}, b
Damian
Re: Perl6 Operator List, Damian's take
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
: '' [~=] 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 Csum,
: Cproduct, and Ccat methods of Array, and the more obscure
: and bizarre reductions be explicitly marked with a Creduce:
:
: my $countersequence = reduce {$^x-$^y}, b
I agree.
Larry
Re: Perl6 Operator List, Damian's take
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. 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/
Re: Perl6 Operator List, Damian's take
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
Re: Perl6 Operator List, Damian's take
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 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 orxor 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 -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl6 Operator List, Damian's take
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
Re: Perl6 Operator List, Damian's take
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 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?
Hmm... I was thinking something along the lines of:
{ $^a op $^b }
[i.e. this change doesn't make any difference]
Luke
Re: Perl6 Operator List, Damian's take
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 ~ - 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
Re: Perl6 Operator List, Damian's take
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
Re: Perl6 Operator List, Damian's take
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.
Re: Perl6 Operator List, Damian's take
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 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
Re: Perl6 Operator List, Damian's take
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 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
Re: Perl6 Operator List, Damian's take
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 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
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/
Re: Perl6 Operator List, Damian's take
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 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
--- Luke Palmer [EMAIL PROTECTED] wrote:
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 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
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/
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Perl6 Operator List, Damian's take
[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
Re: Perl6 Operator List, Damian's take
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, as long as your codepoints don't get above 255, it can still all be done with good old byte-ops. Larry
Re: Perl6 Operator List, Damian's take
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 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Perl6 Operator List, Damian's take
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 officially change
to C| as the low-precidence list composer?
Dave.
ps. for readability, I think most situations require parenthesis
round these mega-lists.
RE: Perl6 Operator List, Damian's take
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 (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
Re: Perl6 Operator List, Damian's take
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
