Lightning flashed, thunder crashed and "Ed Mills" [EMAIL PROTECTED] whispe
red:
| So we establish a var $something=n where n is the array origin.
You mean something like $[, which we've had for many, many years. And
which for many, many years we've discouraged the use of?
$[ The
Damian Conway wrote:
Well, RFC 23 doesn't mention ^0, and has several examples starting
at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
etc. I didn't make it up.
My apologies. The examples you refer to are incorrect. They were added by
a helper, but the
"kinder", but I
don't presume to thinkk like everyone else and others may be more strongly
fixated on another origin.
From: Nathan Wiger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Glenn Linderman [EMAIL PROTECTED]
Subject: Re: RFC 76 (v1) Builtin: reduce
Date: S
"Array and placeholder indices both start at *zero*!"
Sorry for being late, but "why?!"
It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more
expect them to start with ^1, ^2, and so on. It's much more consistent.
But ^1, ^2, etc. have
Damian Conway wrote:
But ^1, ^2, etc. have *nothing* to do with $1, $2, except analogically.
And I'm removing that analogy from the next version of the RFC! ;-)
They have *everything* to do with $_[0], $_[1], $_[2], etc.
I realize this, but I don't think most people will see it that way.
Bart Lateur wrote:
On Thu, 17 Aug 2000 07:44:03 +1000, Jeremy Howard wrote:
$a and $b were done for speed: quicker to set up those global
variables than to pass values through the stack.
The solution is to pass args in as $_[0] and $_[1].
sort { $_[0] = $_[1] } @list
is very ugly.
I
[EMAIL PROTECTED] wrote:
I think all discussion fo RFC 76 (reduce) should be on the new -data
sublist. Jeremy, am I on track here?
You sure are. Any stuff related to data crunching features belongs over
there, please.
Jeremy Howard writes:
: How much hand-waving can we do with implementation efficiency of anonymous
: subs and higher order functions? How much can we expect Perl to optimise
: away at compile time? For instance, if:
:
: $sum = reduce ^_+^_, @list;
:
: has any substantial overhead on each
Jarkko Hietaniemi writes:
: (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
: consider the $ and $b to be warts.)
:
: And anyhow, this will work just fine (see RFC 23):
:
:$sum = reduce ^a + ^b, @numbers;
:
: I have been amply reminded of this, thanks :-)
Well, RFC 23 doesn't mention ^0, and has several examples starting at ^1. And
it draws the analogy between ^1, ^2, etc and $1, $2, etc. I didn't make it up.
So I don't think you're being consistent here. Neither do I consider it an
improvement to add ^0.
While the positional placeholders may
Larry Wall wrote:
Jarkko Hietaniemi writes:
: (Yes, there is a small aesthetic edge in using $a vs $_[0], but I
still
: consider the $ and $b to be warts.)
:
: And anyhow, this will work just fine (see RFC 23):
:
:$sum = reduce ^a + ^b, @numbers;
:
: I have been amply
Damian Conway wrote:
Well, RFC 23 doesn't mention ^0, and has several examples starting
at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
etc. I didn't make it up.
My apologies. The examples you refer to are incorrect. They were added by
a helper, but the
Larry Wall wrote:
Jarkko Hietaniemi writes:
: (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
: consider the $ and $b to be warts.)
Yes, but has anyone pointed out that
@out = sort ^b cmp ^a, @in;
won't do what people will certainly think it ought to?
Damian Conway wrote:
Clever, and really obscure;
"Invisible", rather than "obscure", I would say.
DWIMity of the first order. :-)
wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a ^b, and that everyone
writing a
Except that Perl 6 people will know all about numbered parameters, so they
will write:
@out = sort ^2 cmp ^1, @in;
and it will work just as they expect!
As long as they expect it to fail miserably! :-(
Now, go home and write it out 100 times:
"Array and
Larry Wall wrote:
Yes, but has anyone pointed out that
@out = sort ^b cmp ^a, @in;
won't do what people will certainly think it ought to?
Larry
Well, this will hopefully be moot. I was inspired by discussion here, my
own disdain, and p5p strict issues to write an RFC simply titled
Nathan Wiger [EMAIL PROTECTED] writes:
Jarkko Hietaniemi wrote:
The $a and $b of the sort comparator were A Bad Idea to begin with.
Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
be used, or even a more standard $1 and $2. Either one makes it more
obvious
Piers Cawley writes:
The $a and $b of the sort comparator were A Bad Idea to begin with.
Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
be used, or even a more standard $1 and $2. Either one makes it more
obvious what's being operated on.
$1 $2 could be
While we are here, can reduce itself generate an average? I.e. something
cuter than:
$avg = reduce { $_[0] + $_[1] } @numbers / @numbers;
Of course.
This is about as cute as it gets:
$ave = ${reduce( bless( \(((ref(^x)?$^x*ref(^x):^x)+^y)/((ref(^x)||1)+1)),
19 matches
Mail list logo
