Yuval Kogman wrote:
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
[Bunches of stuff elided.]
A million years ago, $Larry pointed out that when we were able to use
'is just a' classifications on P6 concepts, it indicated that we were
making good forward progress. In that
TSa wrote:
The view I believe Yuval is harboring is the one examplified
in movies like The Matrix or The 13th Floor and that underlies
the holodeck of the Enterprise: you can leave the intrinsic
causality of the running program and inspect it. Usually that
is called debugging. But this
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
On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:
Internally, it may be the same. But with exceptions, it's implemented by
someone other than the victim, and leveraged by all. That's the kind of
abstraction I'm looking for. My problem with the whole notion of Either
errorMessage
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,
On behalf of the Parrot team I'm proud to announce the release of
Parrot 0.3.0. I'd like to thank all involved people as well as our
sponsors for supporting us.
What is Parrot?
Parrot is a virtual machine aimed at running Perl6 and other dynamic
languages.
Parrot 0.3.0 changes and news
- New
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
On 10/1/05, David Storrs [EMAIL PROTECTED] wrote:
All in all, I think that might just be the end of the tunnel up
ahead. Go us for getting here, and loud applause to @Larry for
guiding us so well!
Applause for p6l for hashing out the issues that we didn't think of.
I recently wrote a Perl 6
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
13 matches
Mail list logo
