Miroslav Silovic wrote:
> [EMAIL PROTECTED] wrote:
>
>> And that was never quite resolved. The biggest itch was with
>> operators that have no identity, and operators whose codomain is not
>> the same as the domain (like <, which takes numbers but returns
>> bools).
>>
>> Anyway, that syntax was
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like <, which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more genera
On Sat, Oct 01, 2005 at 02:22:01PM -0600, Luke Palmer wrote:
> And the more general form was:
>
> $sum = reduce { $^a + $^b } @items;
>
> Yes, it is called reduce, because "foldl" is a miserable name.
So, the target of running a loop with both the current
and previous elements accessible cou
Austin Hastings wrote:
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
The subroutine addresses #1, but not 2 or 3.
It does address 2. The list is generated once (wherever) and only pa
Damian Conway wrote:
> Austin Hastings wrote:
>
>> All of these have the same solution:
>>
>> @list = ...
>> for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last, $curr,
>> $next {
>> ...
>> }
>>
>> Which is all but illegible.
>
>
> Oh, no! You mean I might have to write a...sub
On 10/1/05, John Macdonald <[EMAIL PROTECTED]> wrote:
> I forget what the final choice was for syntax for the reduce
> operator (it was probably even a different name from reduce -
> that's the APL name), but it would be given a list and an
> operator and run as:
>
> my $running = op.identity;
On Fri, Sep 30, 2005 at 08:39:58PM -0600, Luke Palmer wrote:
> Incidentally, the undef problem just vanishes here (being replaced by
> another problem).
Which reminds me that this same issue came up a while ago in a
different guise. There was a long discussion about the reduce
functionality that
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 01, 2005 8:53 AM
> To: perl6-language@perl.org
> Subject: Re: Look-ahead arguments in for loops
>
> Austin Hastings wrote:
>
> > All of these have th
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] -> $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
ret
Damian Conway wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Po
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other "we don't need thi
Mark A. Biggar wrote:
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As I remember it zip hrows
On 9/30/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
Thanks. I missed that one.
However, I think your point is pretty much the sam
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Austin~
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> >Austin~
> >
> >On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Plus it's hard to talk about backwards. If you say
> >>
> >>for @l -> ?$prev, $curr, ?$next {...}
> >>
> >>what happens when yo
Matt Fowles wrote:
>Austin~
>
>On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>
>
>>Plus it's hard to talk about backwards. If you say
>>
>>for @l -> ?$prev, $curr, ?$next {...}
>>
>>what happens when you have two items in the list? I think we're best off
>>using signature rules: option
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> >>This is an interesting idea. Perhaps "for" (and "map") shift the
> >>minimum arity of the block from the given list and bind the maximum
> >>arity. Of course, the minimum arity has to be >= 1 lest an infinite
> >>loop
Austin~
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Plus it's hard to talk about backwards. If you say
>
> for @l -> ?$prev, $curr, ?$next {...}
>
> what happens when you have two items in the list? I think we're best off
> using signature rules: optional stuff comes last.
I disagre
Luke Palmer wrote:
>>On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>
>
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
>>
>>
>
>>This is an interesting idea. Perhaps "for" (and "map") shift the
>>minimu
On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
>}
This is an interesting idea. Perhaps "for" (and "map") shift the
minimum arity of the block from the given list and bind the maximum
a
Dave Whipp wrote:
> Imagine you're writing an implementation of the unix "uniq" function:
>
>my $prev;
>for grep {defined} @in -> $x {
>print $x unless defined $prev && $x eq $prev;
>$prev = $x;
>}
>
> This feels clumsy. $prev seems to get in the way of what I'm trying
22 matches
Mail list logo
