Glenn Linderman wrote:
> Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
John Porter wrote:
> Nathan Wiger wrote:
> >
> > Since undef() has established semantics, I don't think these should
> > change. I believe taking from RDBMS and adding null() which has the
> > correct NULL semantics is the way it should go.
>
> You realize, I hope, that there is no end of differe
Nathan Wiger wrote:
>
> Since undef() has established semantics, I don't think these should
> change. I believe taking from RDBMS and adding null() which has the
> correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different "special non-value"
semantics
iain truskett wrote:
>
> Return a specified value (such as 'undef'). It would allow for more
> elegant code, I think. The universe is old enough to cope by itself.
When I first read this, I thought it said:
The universe is old enough to copy itself.
!-)
--
John Porter
Graham Barr wrote:
>
> But what does it do if the block
> is a curried function of three arguments, but the list only contains two ?
Return a curried function of one argument, of course.
At least, that's what it *should* do...
--
John Porter
On Tue, Sep 19, 2000 at 08:14:24PM -0600, Tom Christiansen wrote:
> >Following Glenn's lead, I'm in the process of RFC'ing a new null()
> >keyword and value
>
> As though one were not already drowning in a surfeit of subtly
> dissimilar false values.
Hear, hear.
Three-valued logic is enough.
> Ummm...Maybe I'm missing something, but how does reduce() know the
> difference between
>
> $sum = reduce ^_+^_, 0, @values;
>
> unshift @values, 0;
> $sum = reduce ^_+^_, @values;
There *isn't* any difference. Both versions guarantee that the list
>Ummm...Maybe I'm missing something, but how does reduce() know the
>difference between
>$sum = reduce ^_+^_, 0, @values;
>unshift @values, 0;
>$sum = reduce ^_+^_, @values;
You know, I really find it much more legible to consistently write
these sorts of thing with brac
> In any case, the preferred option should be to provide a default value:
>
> $sum = reduce ^_+^_, 0, @values;
>
> which is always cleaner *and* shorter. :-)
Ummm...Maybe I'm missing something, but how does reduce() know the
difference between
$sum = reduce ^_+^_, 0, @values;
> > $sum = @numbers ? reduce ^_+^_, @numbers : 0;
>
> Although we're back to the pain of what happens when @numbers is
> really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
>
> $sum = fn() ? reduce ^_+^_, fn() : 0;
It would seem likely that most would tr
>Tom suggested:
> > Why not just check @numbers?
>Hear, hear:
> $sum = @numbers ? reduce ^_+^_, @numbers : 0;
Although we're back to the pain of what happens when @numbers is
really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
$sum = fn() ? reduce ^_+^_, fn() : 0
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value
As though one were not already drowning in a surfeit of subtly
dissimilar false values.
--tom
At 04:57 PM 9/19/00 -0700, Nathan Wiger wrote:
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value that will do this:
>
> $a = 1;
> $b = null;
> $c = $a + $b;
>
>$c is null, not 1.
>
>Since undef() has established semantics, I don't think these should
>chan
Graham Barr wrote:
>
> On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
> > Why not just check @numbers?
>
> Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
Following Glenn's lead, I'm in the process of RFC'ing a new null()
keyword and value that will do th
On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
> Why not just check @numbers?
Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
$a = 1;
$b = undef;
$c = $a + $b;
$c is undef, not 1.
Graham.
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> If the reduction subroutine has a prototype, that prototype
Perl6> determines how many items are reduced at a time. If the reduction subroutine
Perl6> is a block or has no prototype, two items are reduced each time.
... is i
Tom suggested:
> Why not just check @numbers?
Hear, hear:
$sum = @numbers ? reduce ^_+^_, @numbers : 0;
Moreover, I suspect that the usual idiom will be:
$result = reduce $reducer, $default, @list;
That is:
$sum = reduce ^_+^_, 0, @numbers;
in which case the "emp
Why not just check @numbers?
--tom
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>
> >Note with the || that way, it'll die immediately if @numbers is empty,
> >even before destroying the universe.
>
> Yes, but why are you passing the size of the array in there?
:-)
And even if you wrote:
Tom Christiansen wrote:
>
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>
> >Note with the || that way, it'll die immediately if @numbers is empty,
> >even before destroying the universe.
>
> Yes, but why are you passing the size of the array in there?
'Cause I'm an idiot, ap
> $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>Note with the || that way, it'll die immediately if @numbers is empty,
>even before destroying the universe.
Yes, but why are you passing the size of the array in there?
--tom
> Even at the risk of Destroying the Entire Universe???
>
> What do others think?
I dunno, seems awfully extreme. Returning undef and testing with "||
die" seems sufficient to me...
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if
> These raise an exception whenever they're feeling curmudgeonly:
>
> glob require substr sysread syswrite write
>
> I presume this would fall in the lattermost category.
Very nicely expressed :-)
Damian
* Damian Conway ([EMAIL PROTECTED]) [20 Sep 2000 08:35]:
[...]
> Even at the risk of Destroying the Entire Universe???
> What do others think?
Return a specified value (such as 'undef'). It would allow for more
elegant code, I think. The universe is old enough to cope by itself.
cheers,
--
ia
On Wed, Sep 20, 2000 at 08:35:20AM +1100, Damian Conway wrote:
>> No other builtin dies like that at
>> runtime. Perhaps a return of undef would be more like other operators.
>
> That was my original proposal, but it was howled down by the
> mathematical elite, who vigorously insisted tha
> > This RFC proposes a builtin C function, modelled after
> > Graham Barr's C subroutine from builtin.pm
>
> Please refer to List::Util rather than builtin.pm
Noted. Thanks.
> the module name was changed as many did not like the name builting,
> as it was not.
Bah. I liked
On Wed, Sep 20, 2000 at 08:22:38AM +1100, iain truskett wrote:
> I'd believe so. I think I mentally assumed that Damian was grabbing a
> syntax trick from another RFC.
Heh, I think the exact same thing is what confused me :-)
> I must say that the ^0, ^1 style notation really makes some expres
On Tue, Sep 19, 2000 at 03:23:30PM -0600, Tom Christiansen wrote:
> >> If the original list has no elements, C immediately throws an
> >> exception.
>
> >What do you mean by exception, die ? No other builtin dies like that at
> >runtime.
>
> Well, more can trigger run-time exceptions than peopl
[...]
Original:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] } [[],[]], @numbers;
Transformed, and made erroneous:
$sorted = reduce { push @{ ^0[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
Transformed correctly:
$sorted = reduce { push @{ ^0->[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @number
13 +
> Date: Tue, 19 Sep 2000 15:43:14 -0500
> From: Jonathan Scott Duff <[EMAIL PROTECTED]>
> Subject: Re: RFC 76 (v2) Builtin: reduce
> In-reply-to: <"from ict"@eh.org>
> To: [EMAIL PROTECTED]
> Reply-to: [EMAIL PROTECTED]
> Message-id:
>> If the original list has no elements, C immediately throws an
>> exception.
>What do you mean by exception, die ? No other builtin dies like that at
>runtime.
Well, more can trigger run-time exceptions than people usually notice,
but I don't know of one that does so on an empty list.
These
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:43]:
> On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
[...]
> > $sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
> I guess I'm confused with the syntax. Shouldn't there be an -> in
> there?
> $sort
> > Collection:
> >
> > @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
>
> You've a typo there
Noted. Thanks.
Damian
On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
> * Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> > On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Builtin: reduce
> [...]
> > > Separation:
> > >
> > > $s
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Builtin: reduce
[...]
> > Separation:
> >
> > $sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
> >
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> This RFC proposes a builtin C function, modelled after Graham Barr's
> C subroutine from builtin.pm
Please refer to List::Util rather than builtin.pm
the module name was changed as many did not like the name builting, as it
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Builtin: reduce
...
> Collection:
>
> @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
You've a typo there, it should be:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_]]
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: 10 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 2
Status: Frozen
38 matches
Mail list logo
