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 i
g been a c "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]>
>Su
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 w
> > "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:
>
>> 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 t
> Still,
>
>sort { $_[0] <=> $_[1] } @list
>
> is very ugly.
Hence:
sort ^a <=> ^b, @list;
Damian
[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.
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
>
> i
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].
Even if you succeed in making access to @_ as fast as access to $a
I think all discussion fo RFC 76 (reduce) should be on the new -data
sublist. Jeremy, am I on track here?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949
> I think this does the right thing too:
>
> @out = sort ^0 cmp ^a, @in;
>
> Since numbered placeholders have higher priority than named, it
> should create the function
>
> sub ($, $a) { $_[0] cmp $_[1] }
> When the curry is evaluated, the a: parameter is bound t
Damian Conway wrote:
> sub sort (^&comparator, @list) {
> for (1..@list**3) {
> my ($i, $j) = (rand(@list), rand(@list));
> @list[$i,$j] = @list[$j,$i]
> unless $comparator->(a: $list[$i], b: $list[$j]);
>
> > Now, go home and write it out 100 times:
> >
> > "Array and placeholder indices both start at *zero*!"
> Array and placeholder indices both start at *zero*!
> Array and placeholder indices both start at *zero*!
> Array and placeholder indices both start at *zero*!
> Array
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
>
To: "Jarkko Hietaniemi" <[EMAIL PROTECTED]>; "Larry Wall" <[EMAIL PROTECTED]>; "Jeremy
Howard" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, August 19, 2000 3:22 PM
Subject: Re: RFC 76 (v1) Builtin: reduc
> 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 responsibility is mine -- for not
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 w
> So that's what I missed, that you expect named actual parameters to
> be legally passable to subs with unnamed formal parameters. I would
> consider that inappropriate, needing at least a warning.
Perhaps under:
use strict 'parameters';
> If people want to use named pa
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
> 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
Clever, and really obscure; wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a & ^b, and that everyone
writing a non-curried sort sub name their parameters a and b? I guess that
wouldn't necessarily be bad, but it would be restrictive.
Damian Conw
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 ou
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 b
Larry pointed out:
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ought to?
It *will*, if C *names* the two values it passes to the
comparator!
E.g.:
sub sort (^&comparator, @list) {
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
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, thank
Nathan Torkington <[EMAIL PROTECTED]> writes:
> 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
Nathan Torkington wrote:
> 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
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 &
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
> ob
> > (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 :-) (Too little time
to spend on RFCs..
Jarkko Hietaniemi wrote:
> On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote:
> >
> >
> > Following the lead of the sort operator, it would be a little
> > simpler to see reduce expressions use $a and $b instead of
> > $_[0], $_[1].
>
> The $a and $b of the sort comparator were A Bad
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 what's being operated on.
It also fixes the "'use
On Tue, Aug 15, 2000 at 11:31:50AM -0500, Adam Krolnik wrote:
>
>
> Following the lead of the sort operator, it would be a little
> simpler to see reduce expressions use $a and $b instead of
> $_[0], $_[1].
The $a and $b of the sort comparator were A Bad Idea to begin with.
There's nothing wron
Following the lead of the sort operator, it would be a little
simpler to see reduce expressions use $a and $b instead of
$_[0], $_[1].
E.g.
Summation:
$sum = reduce{$a + $b} 0, @numbers;
$sum = reduce sub{$a + $b},0, @numbers;
Production:
> A better example might be trying to perform join, with reduce eg
>
> reduce __.','.__ $identity, @list
>
> Which would not work for any value of $identity unless you did
>
> reduce __.','.__ shift @list, @list
>
> which is probably a good example why not to req
On Fri, Aug 11, 2000 at 10:51:45AM -0400, John Porter wrote:
> Damian Conway wrote:
> >
> > More and more I lean towards a scalar-only reduce.
>
> Yep!
Have you stollen my brain :)
Graham.
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote:
>> Okay, then for
>>
>> reduce &avg $identity, @list
>>
>> What should $identity be?
GB> I would like to see what &avg would be, given that each time it
GB> would be passed
Bart Lateur wrote:
>
> I have some reservations about this reduce() thing. Plain and simple
> incorporating it into the core language would introduce the chance for
> lots of buggy programs, like the example Arial gave. In fact, I think
> that *most* programs that use reduce() would be buggy.
W
John Porter <[EMAIL PROTECTED]> writes:
> > Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
> > multidimensionals.
>
> Combined with highlander variables, and there ceases to be a problem.
Will you stop with the highlander variables?
--
Piers
Damian Conway wrote:
>
> More and more I lean towards a scalar-only reduce.
Yep!
> Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
> multidimensionals.
Combined with highlander variables, and there ceases to be a problem.
--
John Porter
On Fri, Aug 11, 2000 at 01:20:36PM +0200, Bart Lateur wrote:
> I think we don't really need reduce(). There are well working,
> relatively simple, and *far more transparent* alternatives, at least,
> for Perl. We do have OP= operators, after all. For example:
>
> $total = 0;
> map { $
On Thu, Aug 10, 2000 at 07:22:21PM -0400, Chaim Frenkel wrote:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
I would like to see what &avg would be, given that each time it
would be passed the previous result (or the first element) and
the next element.
On 11 Aug 2000 09:30:03 +0300, Ariel Scolnicov wrote (and quoted):
>> reduce &avg $identity, @list
>This was my first point regarding C -- not all functions have
>an identity element. One should note that in general
>
>(reduce &avg $x,@list) != (reduce &sum 0,@list)/@list
>
>for I valu
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
This was my first point regarding C -- not all functions have
an identity element. One should note that in general
(reduce &avg $x,@list) != (reduce &sum 0,@lis
> > Currying placeholders are scalars
>
> Is that a general truth?
Yes. It proceeds from the fact that $_[0], $_[1], ect are scalars.
> It wasn't obvious from RFC 23... If you
> rev it, perhaps you could make that clearer.
Will do.
> Looking back, the defining exampl
Damian Conway wrote:
> Currying placeholders are scalars
Is that a general truth? It wasn't obvious from RFC 23... If you rev it, perhaps
you could make that clearer.
Looking back, the defining example did give a list of (;) in the prototype. I
suppose it would be pretty complex to infer
Chaim Frenkel wrote:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
>
What's wrong with:
$average = reduce (^last+^this, @^list) / scalar @^list;
print $average->([1,3,5]); # Prints '3'
You don't need to explicitly add a '0' to the front of the summed list.
Okay, then for
reduce &avg $identity, @list
What should $identity be?
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
AS> Think of the first element of the list as different from the rest --
AS> it is the initial value to reduce from (for + and *, you'll usually
AS> pick an
> Couldn't reduce return a list just through concatenating its elements? For
> instance:
>
> @a = (1,3,2,4,3,6,4,8);
> @sum = reduce( (^total, ^x+^y ), @a ); # (4,6,9,12)
Currying placeholders are scalars, so you want:
@sum = @{reduce (@^total, ^x+^y ), [], @a };
More
Damian Conway wrote:
>> AS> Also, the RFC should specify that the function is always
evaluated in
>> AS> a scalar context (for things to make sense).
>>
>> Why? reduce should be able to reduce a set of matrices to a matrix.
Or
>> actually any aggregate (plural whatzit).
>>
> By writing @sum = reduce __+__ 0, @numbers
> you deal elegantly with both cases.
>
> NOTE: I find this trick very elegant. I wish it were my trick,
> instead of Damian's...
Damian wishes it were Damian's, but is sure it's at least a few hundred
years old :-)
Damian
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
>
> >> If the original list has no elements, C immediately returns C.
>
> AS> I like everything except this part. Reducing an empty list should be
> AS> an error.
>
> AS> Returning undef (or
> I don't see it.
>
>1 == f((reduce +, undef), 1) == reduce +, undef, 1
undef isn't an empty list, it's a one element list.
Consider the other "common" reduction:
sub f { $_[0] * $_[1] }
Now:
f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0
But
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
>> If the original list has no elements, C immediately returns C.
AS> I like everything except this part. Reducing an empty list should be
AS> an error.
AS> Returning undef (or anything else, really) breaks the algebraic
AS> equivalence
Perl6 RFC Librarian <[EMAIL PROTECTED]> (but actually it was Damian
Conway) writes:
> If the original list has no elements, C immediately returns C.
I like everything except this part. Reducing an empty list should be
an error.
Returning undef (or anything else, really) breaks the algebraic
eq
> 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)),
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> And for the N case, it gets even uglier. So reduce should be able
>> to supply the next N-1 defined() values.
DC> $def_sum = reduce { $_[0]+$_[1] } grep {defined} @numbers;
Fine.
Even better if the optimizer could recognize the id
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
DC> For example, to short-circuit if the reduction ever becomes undef:
DC> $sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;
Chaim> Actually, it would be easier to do in reduce, the undefs should
Chaim> simply be ignored.
If I
> Actually, it would be easier to do in reduce, the undefs should
> simply be ignored.
>
> Otherwise having the user code it, becomes
>
>{ defined $_[0] && defined $_[1] ? $_[0] + $_[1]
>: defined $[0] ? $_[0] : $_[1] }
>
> Pretty ugly.
>
> And
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> I'm not sure how this would affect the proposal. If an item in the
DC> list being reduced is undef, it appears in the reduction
DC> subroutines arg list as undef. The reduction subroutine can then
DC> handle it (or not) as it chooses.
> >Builtin: reduce
>
> There are some things unspecified. Specifically 'special' reduce variables.
> You've got:
>
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers;
> > $sum = reduce ^_+^_,0, @numbers;
> > $min = reduce ^x <= ^y ? ^x :
At 02:46 PM 8/9/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Builtin: reduce
There are some things unspecified. Specifically 'special' reduce variables.
You've got:
> $sum = reduce {$_[0]+$_[1]} 0, @numbers;
> $sum = reduce ^_+^_,0, @numbers;
> $
On 09 Aug 2000 13:49:24 -0400, Chaim Frenkel wrote:
>Assuming a "use tristate", undef + number = undef
>
>This might require that the reduce function be able to ignore undefs.
>Either always under the tristate pragma. Or on a case by case basis.
grep defined, LIST
--
Bart.
> Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL.
>
> Assuming a "use tristate", undef + number = undef
>
> This might require that the reduce function be able to ignore undefs.
> Either always under the tristate pragma. Or on a case by case basis.
I'm no
Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL.
Assuming a "use tristate", undef + number = undef
This might require that the reduce function be able to ignore undefs.
Either always under the tristate pragma. Or on a case by case basis.
Also you haven't specified if the ar
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 76
=head1 ABSTRACT
This RFC proposes a builtin
67 matches
Mail list logo
