[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
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
$sum =
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. Possible
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) {
-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 the same solution:
@list = ...
for [undef, @list
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
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;
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...subroutine!??
Austin
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
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 could be
On Thu, Sep 29, 2005 at 11:21:20PM -0600, Luke Palmer wrote:
[ discussion on undefs elided ]
Since we can annotate our undefs now, perhaps undefs that would be
generated because there are no previous or next elements get tagged
as such. Something like:
# assuming $b and $a are before
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 you have two items in the list? I
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
Damian
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 same 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
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 {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other we don't need
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 to
say. Could we imbue optional
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 to
say.
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
arity. Of
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
minimum arity of the block from the given list
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 disagree, I
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 occur.
Or not.
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: optional stuff comes
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Matt Fowles wrote:
for (1, 2) - ?$prev, $cur, ?$next {
say $prev - $cur if $prev;
say $cur;
say $cur - $next if $next;
say next;
}
[...]
I assume so because it's the only execution path that seems to work. But
that
25 matches
Mail list logo
