in reply to Re: A set of new operators. In keeping with the design of Perl?
in thread A set of new operators. In keeping with the design of Perl?

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
  • Comment on Re: Re: A set of new operators. In keeping with the design of Perl?

Replies are listed 'Best First'.
Re: Re: Re: A set of new operators. In keeping with the design of Perl?
by TheDamian (Vicar) on May 20, 2003 at 07:26 UTC
    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; }

    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 >
    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;

      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; }

      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
        I feel a bit like the kid outside the sweet shop (candy store), or toy shop. Allowed to look, but not to touch:)
        We (the designers) feel that way too! Unfortunately both the design and the implementation are currently unfunded volunteer efforts, sandwiched in between our day jobs (or, increasingly, our search for a day job). That translates to a development process far slower than any of us would prefer. :-(
        I find all of that extremely readable. Obviously your copius comments and context help, but it still bodes well for the future.
        Thank-you. We've worked incredibly hard on keeping Perl 6 Perlish; tried to make it even more Perlish, in fact. Of course, threshing True Perl™ out the myriad of possibilities also contributes to the slowness of development.
        I see you using (what I take to be) the P6 equivalents of P5s $a and $b.
        Not quite. $^a and $^b are "placeholder variables". Every block in Perl 6 is really an anonymous subroutine. Putting a placeholder in a block is one way of giving that anonymous subroutine a parameter. Putting two in a block, gives the block/subroutine two parameters. Etc. etc.
        Apart from that they are presumable properly scoped removing the old global clash fears,
        Indeed. Like all subroutine parameters, they are lexically scoped to the body of the subroutine. In this case, to the block itself.
        are they limited to just those two?
        No. Any subroutine can have any number of parameters. Hence, any block can have any number of placeholders.
        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?
        You can specify as many placeholders as you like. However, the reduce built-in will not compute a moving average for you. It takes the data list you provide and successively extracts as many elements as there are parameters to the reduction block. To get a moving average, or moving maximum, or moving whatever, we'd need a function that takes an N-argument subroutine and moves it over a window. For example:
        sub moving (&func, *@data) { # Note: "arity" means how many params the sub takes my @results; for 0..@data-&block.arity -> $from { my $to = $from + &block.arity - 1; push @results, func(@data[$from..$to]); } return @results; } @average_3 = moving { ($^x+$^y+$^z)/3 } @values; @average_4 = moving { ($^w+$^x+$^y+$^z)/4 } @values; @local_max_3 = moving { max $^x, $^y, $^z } @values; # etc.
        Will @args (and @values) be implemented as a list or an iterator?
        Arguments passed to a *@parameter are passed lazily, as an iterator tied to an array interface.
        Do you have any feel for whether calling subs in P6 will have a lower overhead than P5?
        That's a core design goal.
        Does multi infix:max= happily combine with the multi max subs above?
        Yes. That's exactly why I wrote it that way. ;-)

        BTW, if anyone wants more detail, most of this is described in Apocalypse 6, summarized in Synopsis 6, and explained in the forthcoming Exegesis 6.