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?

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]

I feel a bit like the kid outside the sweet shop (candy store), or toy shop. Allowed to look, but not to touch:)

Surprisingly, despite the fact that my only knowledge of P6 syntax is that gleaned from a few passes through the Apocolypsies and Exegisies (sp x2?), along with your occasional posts here, I find all of that extremely readable. Obviously your copius comments and context help, but it still bodes well for the future.

A few questions arising, if you have the time

I see you using (what I take to be) the P6 equivalents of P5s $a and $b. Apart from that they are presumable properly scoped remooving the old global clash fears, are they limited to just those two? By which I mean, if I need to look at more than two elements of the argument array at a time (eg. a moving averages calculation) can I get to them through $^c, $^d etc? Does this thought make any sense? (Semi-rhetorical).

Will @args (and @values) be implemented as a list or an iterator?

Do you have any feel for whether calling subs in P6 will have a lower overhead than P5?

Finally (for now at least), in your previous post below, you showed this

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

Does that happily combine with the multi max subs above?

---

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