Perhaps the best example of this is $var ||= 100; which is shorthand for $var = 100 unless $var; or even if( not $var ) { $var = 100; }

Actually, it's a shorthand for $var = $var || 100;, just like how $var += 4; is a shorthand for $var = $var + 4;

?<:= ?>:= ?<=:= ?>=:= ?lt:= ?gt:= ?ge:= ?le:=

I don't like them. Too hard to remember and too ugly.

maybe in perl 6?

http://dev.perl.org/perl6/list-summaries/p6summary.2003-02-09.pod.html#shortcut%20=

Finally, is it possible to invent new operators using overload? Or would you have to resort to source filters to implement this outside of the core?

No; yes.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Thanks for the link juerd, I hadn't seen that discussion. However, I think that my idea is quite different to that proposal which suggested a short-hand for the trinary operator involving 3 operands.

eg. $var ??= $x : $y;

The operators I am seeking only involve 2 operands.

Too hard to remember ...

This: $var = $var op $expr ? $var : $expr;

becomes this: $var ?op:= $expr;

Is that hard to remember?

...and too ugly.

Agreed, they ain't beauiful. I was trying to retain the notions of the ternary and the operators and the assignment, but as they are no longer ternary, maybe the ? or the final = could be dropped:

# Instead of these               these or               these?
$lvalue  ?<:= $rvalue;   $lvalue  <:= $rvalue;   $lvalue ?<:  $rvalue;
+     
$lvalue  ?>:= $rvalue;   $lvalue <=:= $rvalue;   $lvalue ?>:  $rvalue;
+     
$lvalue ?<=:= $rvalue;   $lvalue  >:= $rvalue;   $lvalue ?<=: $rvalue;
+     
$lvalue ?>=:= $rvalue;   $lvalue >=:= $rvalue;   $lvalue ?>=: $rvalue;
+     
$lvalue ?lt:= $rvalue;   $lvalue lt:= $rvalue;   $lvalue ?lt: $rvalue;
+     
$lvalue ?gt:= $rvalue;   $lvalue le:= $rvalue;   $lvalue ?gt: $rvalue;
+     
$lvalue ?ge:= $rvalue;   $lvalue gt:= $rvalue;   $lvalue ?ge: $rvalue;
+     
$lvalue ?le:= $rvalue;   $lvalue ge:= $rvalue;   $lvalue ?le: $rvalue;
[download]

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

In Perl5, you cannot define new operators using overload. You can give new meaning to existing operators though. So you could always pick an operator you hardly use, and give the meaning like you give for instance ?le:=, use that for a while and see whether you really use that so often it would warrant inclusion in the Perl core.

As for // and //=, the development track for 5.9.0 has those operators.

Abigail

Seriously: I don't think I have had use for your suggested operators more than a couple of times, and so I don't think it would be worth the trouble. Implement them as functions - that would get rid of the evaluate twice problem.
You can even call them meaningfull and pretty names like 'max', 'min' and so on.
Wouldn't that solve your problems?

Perl 6 will have built-in n-ary min and max operators.

But they almost certainly won't have assignment versions, until some evil person writes:

module In::Extremis;

multi infix:max= (Num $curr is rw, Num $new) is exported {
    $curr = max $curr, $new;
}

multi infix:min= (Num $curr is rw, Num $new) is exported {
    $curr = min $curr, $new;
}
[download]

Oops! Too late. ;-)

Having cut my teeth on C back in the late 70's, I think the "old-timers" is probably a closer fit to me, than "young whipper-snapper", but both points taken:)

Codifying the operators into subs like 'min' and 'max' works where the semantics of the operation fits the names, which isn't always the case, but there are a couple of problems with that.

You need a 'min_str', min_str_i' and 'min_num' to really cover all bases.

The cost of building stack frames for an operation where all the information the compiler needs to make the assignment is available right there in the expression seems proflagate.

Were it possible for the compiler to do sub-expression elimination that might eleviate some of the problem, but then you need to make special cases for the possibility that the double side effect is actually what the programmer intended (as horrendous doing so would be:), I would stil have to type/maintain both instances of both operands though. Not onnerous, but another source of potential bugs.

The P6 macro facility might address some of the issues, but the double-side-effects problem of C macro fame would probably persist. I haven't gleaned enough information on the P6 object mechanisms yet to work out whether it is possible to add operators/methods to the base 'types'.

Maybe TheDamian or Elian know?

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

You need a 'min_str', min_str_i' and 'min_num' to really cover all bases.

You can get most of the way there with multimethods. Which, fortunately, Perl 6 has:

multi max (Str *@candidates) { 
    reduce {$^a gt $^b ?? $^a :: $^b} @candidates;
}

multi max (Num *@candidates) { 
    reduce {$^a > $^b ?? $^a :: $^b} @candidates;
}
[download]

However, I suspect that won't be sufficiently Lazy for Perl 6. So my preference is for a max function that selects what kind of comparison to do, based on call context:

sub max (*@args) { 
    if want~~Str { reduce {$^a gt $^b ?? $^a :: $^b} @args }
    else         { reduce {$^a > $^b ?? $^a :: $^b} @args }
}

$biggest_str = ~max @values;  # Str context, so use gt
$biggest_num = +max @values;  # Num context, so use >
$biggest_num =  max @values;  # scalar context, default to >
[download]

And to get all the way there (i.e. to allow for user-specified comparisons such as case-insensitive), max would have an optional closure argument (just as sort does now) so that the comparator could be explicitly specified:

# Let call context decide...
multi max (*@args) { 
    if want~~Str { reduce {$^a gt $^b ?? $^a :: $^b} @args }
    else         { reduce {$^a > $^b ?? $^a :: $^b} @args }
}

# Let the user specify...
multi max (&compare, *@args) {
    reduce {compare($^a,$^b)>=0 ?? $^a :: $^b} @args;
}

$biggest_str    = ~max @values;
$biggest_num    = +max @values;
$biggest_num    =  max @values;        
$biggest_mag    =  max {abs $^a <=> abs $^b}  @values;
$biggest_lookup =  max {%hash{$^a} cmp %hash{$^b}  @values;
[download]

It wasn't an efficiency issue (for a change:), it was my other windmill, that of elegance, 'once and once only', duplcated code is two chances to get wrong etc.

Realise that there i no way to avoid (in assembler terms), loading the two values, comparing them, branching if condition not satisfied, do the assignment.

But avoiding the need for the programmer to type the terms twice each as well as the potential for invoking the rvalue expression twice when it could be a volatile function or one with side effects appealled to me.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

I disagree - I think you need to evaluate the conditional once in scalar or list context, as appropriate, and then evaluate that result in a boolean context. Which implies that if the conditional involves an expensive operation, that operation need only be invoked once.

Of course, people that write clever stuff would need such behaviour documented, but that'd be true whichever approach were selected. And with the entire grammar so mutable, chances are a couple of extra lines in the docs could even show how to avoid this behaviour.

Hugo

We also have the ternary operator ? : ; which is often used in expressions like

That'll be  ?? :: in Perl6.

?>:=
[download]

I think that is too much information to store in 4 ASCII characters. Some might argue that ? : already goes too far with information-packing. I personally learned C/C++ in a high school class (one of the very few languages I actually took a structured class for) and was never taught about the ? : operator. I never saw it until I learned Java, and even then I almost never used it until I learned Perl. It was a shortcut (and one of the things Java avoids religiously is shortcuts), and I didn't really "get it" for quite some time. Naturally, Perl religiously embraces shortcuts, but I think the operators you propose go too far.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Maybe... Would it still be if the operators used the names TheDamian suggested (for the following two cases)?

$x =min $x, $y; # p5
$x ?>:= $y;     # my half-assed notion:)
$x min= $y;     # p6+

$x =max $x, $y; # p5
$x ?<:= $y;     # Mine
$x max= $y;     # p6+
[download]

The most recent situation where I encountered this was

for ( 0 .. $#{ $hash{$set}{data} } ) {
    $hash{$set}{min} = $hash{$set}{min} < $hash{$set}{data}[$_]
                     ? $hash{$set}{min} 
                     : $hash{$set}{data}[$_];
}
[download]

which starkly demonstrates the problem. Contrast that with

$hash{$set}{min} ?<:= $hash{$set}{data}[$_] for 0 .. $#{ $hash{$set}{d
+ata} };
[download]

Which is easier to read?

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

for ( 0 .. $#{ $hash{$set}{data} } ) {
    $hash{$set}{min} = $hash{$set}{min} < $hash{$set}{data}[$_]
                     ? $hash{$set}{min} 
                     : $hash{$set}{data}[$_];
}
[download]

I personally find the above solution easier to read. However, since this is in a loop, and regular ? : evaluates the data twice, your proposed operator could be considerably faster in some cases. Naturally, the premature optimization alarms are ringing here, so I'm going to stop typing now (:

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

$x =min $x, $y; # p5
[download]

For me that's perfect. A function min - thats just three chars, you add = and what you have is the same number of chars (for golfers), much more clear than ?<:=, and more flexible - it can handle lists instead of just pairs.
Update: Sorry this was just just a temporary blurr of my consiousness. It did not address the arguments by BrowserUk.

I think you should at least consider writing such code more like:

my $set = $hash{$set};
my $data = $set->{data};
for (@$data) {
  $set->{min} = $set->{min} < $_ ? $set->{min} : $_;
}
[download]

Hugo

use List::Util qw(min);
$hash{$set}{min} = min @{$hash{$set}{data}};
[download]

I love that module. Thank goodness it's in the core since 5.8. Of course that doesn't address your beef, but in this case I think you're looking for aliasing, not a condensed form of the ternary. Some of that is available with Perl5 already, had you phrased your loop differently:

for (@{$hash{$set}{data}}) {
    $hash{$set}{min} = $hash{$set}{min} < $_
        ? $hash{$set}{min}
        : $_;
}
[download]

And in Perl6 (I'm probably getting the syntax wrong) it'd be something like:

my $min := $hash{$set}{min};
for(@{%hash{$set}{data}}) { $min = $min < $_ ? $min : $_ }
[download]

Makeshifts last the longest.

It would be usefull to count the use of some language constructs on some big standard sample - to have the numbers. The difficult thing would be to agree on what a standard sample is.

Well, a grep of my codebase (the obvious choice:) show that the ternary shows up at least once in approx. 60% of all my programs. Convinces me:)

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

But you should count it comparatively - for instance what is the percent of programs using the  + operator. And the shortcut  +=?

Perhaps something like number_of_operator_uses / LOC_of_the_probe would be a better number than the procentum of programs.

Just because you write the variable once, this doesn't means that it will be called once in the interpreter. For example:

  $x = $x * $y ;

  ## With the Syntax Suger:

  $x *= $y ;
[download]

But this are different:

  $var = $var . 'xyz' ;

  $var .= 'xyz' ;
[download]

So, how do you think that the interpreter will work with this 2 ways?:

  $latest = $latest > time() ? $latest : time();

  ## With your Syntax Suger:
  $latest ?>:= time() ;
[download]

  ## Probably what should be made internally:
  my $tmp = time() ;
  $latest = $tmp if $latest > $tmp ;
[download]

Graciliano M. P.
"The creativity is the expression of the liberty".