(or "Allowing built-in functions to use loop blocks")
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting C, C, and C with C
(or "Allowing built-in functions to use loop blocks")
=head1 VERSION
Maintainer: Garr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Predefined POD Streams are C, C, and C
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 9 Aug 2000
Last Modified: 7 Sep 2000
Number: 79
Versio
> Shoot chop. and chomp. Unless you add unchop and unchomp.
C *has* an inverse.
Surely you know about the unary postfix C<.$/> operator?
Of course, you have to be careful. There's a known bug that
the C<.$/> doesn't properly "unchomp" if you've ever used the
C<$/&=``> operator.
;-)
Damian
On Fri, Sep 08, 2000 at 02:50:37AM +, Ed Mills wrote:
> Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
> a language with YES and no NO.
>
> Just kill then both.
Although I'm rather fond of symmetry, it's not inherently good.
Rather boring if overused.
I admit
>Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
>a language with YES and no NO.
By that criterion, you have zillions of other things to kill.
>Just kill then both.
I don't think this will win us friends.
--tom
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
Just kill then both.
>From: Bryan C. Warnock <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Michael G Schwern <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: RFC 195 (v1) Ret
Does this discussion pertain to a particular RFC? If so, could the RFC
number please be quoted in the subject?
If it's not already RFC'd, who will volunteer to do it?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level
On Thu, 07 Sep 2000, Michael G Schwern wrote:
> Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
Someone, (and I've lost who, exactly) was interested in taking those
off my hands for a String::Utils module.
I believe it was quite clear, however, that my root-and-measure-deri
Damian Conway wrote:
>
>> Both are pretty much the same. Combining them, I'd say that exceptions
>> should remain exceptional.
>
> I'd say short-circuiting a vector operation was exceptional enough. :-)
I'd say it's exceptional sometimes, and very ordinary other times, and
I'd prefer to
> Both are pretty much the same. Combining them, I'd say that exceptions
> should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
> Counterproposal: grep, map, etc. define two implicit magic labels
> 'ACCEPT' and 'REJECT' that behave in th
>Counterproposal: grep, map, etc. define two implicit magic labels
>'ACCEPT' and 'REJECT' that behave in the expected way, so you use
>($first_small) = grep { ($_ < 2) and last ACCEPT } @list.
Reminds me of "next LINE" in perl -p or perl -n.
--tom
Damian Conway wrote:
>
>> > I would propose that the C operation should short-circuit if the
>> > block throws an exception, with the value of the expection determining
>> > whether the final invocation of the block should accept the element it
>> > was filtering:
>>
>> Ot
> > 'Pends on whether you modulate them.
>
> KCHP 1570 on your AM dial!
Aw, not *another* one of those easy-listening Californian motor cop stations!
Damian
On Thu, Sep 07, 2000 at 06:48:35PM -0600, Tom Christiansen wrote:
> >Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
>
> 'Pends on whether you modulate them.
KCHP 1570 on your AM dial!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just A
>On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
>> =head1 TITLE
>>
>> Retire chop().
>Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
--tom
> I don't think C should be able to eat unintentional exceptions.
> Perhaps it could short-circuit if the exception is 1 or false, as
> opposed to true or false?
No objection here.
Damian
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant
> Exactly the sort of chicanery grep/last is meant to avoid. So the question
> becomes, how do we crowbar "last" in without altering the returned value in
> C blocks. I'm for putting it after a comma. Which matches the syntax of
> John Porter's proposal about internally converting the block to a
On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote:
> I would propose that the C operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
I do
Damian Conway wrote:
> A C such as:
>
> @array = grep BLOCK LIST
>
> is equivalent to:
>
> @tmp = ();
> foreach (LIST) { push @tmp, $_ if do BLOCK }
> @array = @tmp;
>
> That similarity would not change in any way under the proposal
> (except to be made stronge
John Porter wrote:
> heh. for a normal sub,
>
> sub foo {
> return( 42 );
> }
>
> finds OMWTDI as
>
> sub foo {
> 42;
> last;
> }
>
> Somehow, this seems like very natural perl to me.
>
> --
> John Porter
I'd
The "assignment from a lazy list" section of RFC 123 suggests a system
for requesting the first however many items out of a map or grep by
making it lazy and then assigning it to an array of that size.
"last" is more flexible, if you are looking for a condition more
complex than the first one,
> > I would propose that the C operation should short-circuit if the
> > block throws an exception, with the value of the expection determining
> > whether the final invocation of the block should accept the element it
> > was filtering:
>
> Otherwise nice but until now die() ha
> I would propose that the C operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
Otherwise nice but until now die() has been a serious thing, now it
> If one were looking for the first matching item, last would work:
>
>grep { /pat/ and last } @foo
># return()s the value of $_=~/pat/, which will be true
Huh? I can't see how that could work unless you change the existing
semantics of C and C.
Let's take a step back and an
Johan Vromans wrote:
> my $file_format = qf(
> @<: @
> $name, $ssn
> );
>
> Now, $file_format would be a Format object (compare this with qr//,
> that produces a Regex object).
or the proposed qs// which would produce a packed structure definition
Damian Conway wrote:
>
> The expression C<1 and last> does *not* evaluate to true -- it does not
> evaluate to *anything*. So the C is terminated by the C
> without the block having ever evaluated true. So no element of LIST is
> ever "passed through". So the C evaluates to zero.
Right. Well, pe
Jarkko Hietaniemi wrote:
>
> How about using 'return', then? That could, ahem, return both true and
> false values.
Hmm. I think it boils down to the fact that we'd like a grep block
to have characteristics of both a subroutine and a true loop block.
Here's a proposal which would mostly elim
John Porter wrote:
>
> David L. Nicol wrote:
> >
> > A bareword inside doublequotes is not interpreted, in Perl or C.
>
> No; a "bareword" in quotes (any kind) is not a bareword.
>
> --
> John Porter
huh?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
On Thu, Sep 07, 2000 at 10:05:58PM +0200, Bart Lateur wrote:
> On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>
> >But it makes "short-circuit as soon as C
> >lets through a specific value" ugly:
> >
> >my $seen;
> >$has_odd_elem = grep { $seen && last; $_%2 && ++$s
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>But it makes "short-circuit as soon as C
>lets through a specific value" ugly:
>
>my $seen;
>$has_odd_elem = grep { $seen && last; $_%2 && ++$seen } @numbers;
Not just ugly. Useless.
--
Bart.
John wrote:
> > I don't know how grep works internally. I don't know if grep pushes
> > elements into @a one at a time, or if it returns a finished list of
> > elements which pass the conditional block. If it is the latter as I
> > assume, a short-circuited grep would return a list o
Garrett wrote:
> It almost feels like grep could have been written like this (in
> another life): @a = grep (@b) { $_ > 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
> While I'm at it, I'm curious as to why:
>
> $a = 2;
> @b = (1,
Bart wrote:
> >The last operator doesn't return anything does it? It immediately
> >exits the loop/block in question.
This is correct.
> But then, what is the value that would be returned to grep()? If you use
> 0 as the last value evaluated inside the block, grep() would return an
Garrett Goebel wrote:
>
> Let's see if I've got this straight. To paraphrase Damian's
> RFC 77 for reduce:
>
> If a C's block were terminated by a call to C,
> grep immediately returns the last block value (i.e. C
> on the first block call, $_[0] otherwise). Or maybe that's @_
> otherwise...
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
> >> > grep { $a > $_ and last } @b)
> >>
> >> So "last" should return true, or what?
> >
> >The last operator doesn't return anything does it? It
> >immediately exits the loop/block
"Myers, Dirk" wrote:
> $mode = 0755 ;
> $file = "Foobar" ;
>
> #include
> #include
>
> chmod($mode, $file) ;
>
> Which chmod gets called, perl or C? What are the rules for figuring this
> out?
>
> Dirk
Following the documentation at
http://www.pe
On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
>> > grep { $a > $_ and last } @b)
>>
>> So "last" should return true, or what?
>
>The last operator doesn't return anything does it? It immediately exits the
>loop/block in question.
But then, what is the value that would be retur
Bart Lateur wrote:
>
> >Currently, attempting to use objects in a string context
> >yields garbage:
> >
> > print "r is $r->func"; # "OBJ=HASH(0xef958)->func"
> > print "r is ", $r->func; # works, but clumsy
>
> Does this expand to regexes?
>
> /$foo->blah/
>
> To be conseque
On 14 Aug 2000 23:29:38 -, Perl6 RFC Librarian wrote:
>Currently, attempting to use objects in a string context
>yields garbage:
>
> print "r is $r->func"; # "OBJ=HASH(0xef958)->func"
> print "r is ", $r->func; # works, but clumsy
I've not seen any comments on this RFC yet. But thi
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> From: Garrett Goebel
> > @passed = grep { 2 > $_ and last } (1, 2, 3, 2, 1);
> >
> > would leave
> > @passed = (1, 2)
>
> I believe the above would leave:
>
> @passed = ();
>
> since on the first call to the block 2 > 1 is true, so th
Having no time to write and/or maintain RFC's, I'll toss this up in the air
and see what happens.
Abigail has posted sorting benchmarks for 5.6.0 to 5.7.0 on clp.misc, and I've
extended that being curious to performance loss for anonymous blocks and named
subroutines
sub Xcmp { $a cmp $b
42 matches
Mail list logo
