in reply to Re: Re: 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?

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

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

    [download]
    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.

[reply]
[d/l]
[select]

      And thank you. For taking the time, both to explain and for your continuing sterling (or should that be AU$) work.

      Hmmm. What we need is a P6@home screen saver, or maybe we could surgically implant Q::S somewhere strategic:).

      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
[reply]

In Section Meditations