Re: Perl6 Operator List, Damian's take

[Larry Wall]

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 C,
: C, and C methods of Array, and the more obscure
: and bizarre reductions be explicitly marked with a C:
: 
:   my $countersequence = reduce {$^x-$^y}, @b

I agree.

Larry

Re: Perl6 Operator List, Damian's take

[Damian Conway]

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 C,
C, and C methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a C:

	my $countersequence = reduce {$^x-$^y}, @b

Damian

Re: Perl6 Operator List, Damian's take

[Larry Wall]

On Wed, 30 Oct 2002, John Williams wrote:
: They are different in the "scalar [op] list" case, as explained here:
: 
: 
: ($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

[John Williams]

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:


($a = 0) [+=] @b;   # sum
($a = 1) [*=] @b;   # product
($a ='') [~=] @b;   # cat

~ John Williams

Re: Perl6 Operator List, Damian's take

[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

RE: Perl6 Operator List, Damian's take

[Larry Wall]

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

[David Whipp]

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

[Dan Sugalski]

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

[Larry Wall]

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

[Simon Cozens]

[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

[Austin Hastings]

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

[Luke Palmer]

> 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

[Damian Conway]

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

[Aaron Crane]

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

[fearcadi]

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" _ 

   *   _  surrounded by spaces is placeholder if term is expected
   *   _postfixop  "carriage-returns" and binds  the operator to
  previous term
   *  term_  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

[Dave Mitchell]

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]

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

[Damian Conway]

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

[Luke Palmer]

> 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

[Damian Conway]

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

[Uri Guttman]

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

  DC> Oh boy, I just *hate* the idea of C 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]

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

Perl6 Operator List, Damian's take

[Damian Conway]

Oh boy, I just *hate* the idea of C 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;
	@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 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   orxor   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