Re: EX3: $a == $b != NaN
On Sun, 7 Oct 2001 12:27:17 +1000 (EST), Damian Conway wrote: The step you're missing is that the non-numeric string hello, when evaluated in a numeric context, produces NaN. So: hello == 0 0 != NaN is: Nan == 0 0 != NaN which is false. So to what does 123foo evaluate in numeric context? Now, it produces 123. Which is probably useful... if 123foo produces Nan, which wouldn't really surprise me too much, we'll need additional tools to extract the number from a string. We can do it with a regex, but for the general case, it becomes a nasty beast of a regex, and I don't want to rewrite it from scratch every time I need it.A job for Regexp::Common? -- Bart.
Re: EX3: $a == $b != NaN
On 10/6/01 10:27 PM, Damian Conway wrote: Doesn't that mean: hello == 0 0 != NaN will evaluate to true? No. The step you're missing is that the non-numeric string hello, when evaluated in a numeric context, produces NaN. So: hello == 0 0 != NaN is: Nan == 0 0 != NaN which is false. Heh, my brain's Perl interpreter needs to be upgraded, obviously. It sees hello == 0 and produces 0 == 0. Thanks for the clarification :) -John
RE: $a in @b (RFC 199)
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Jarkko Hietaniemi
I find this urge to push exceptions everywhere quite sad.
Rather.
Languages that have forgotten or dismissed error returns, turning
instead to exceptions for everything in an effort to make the code
"safer", tend in fact to produce code that is tedious and annoying.
There seems to be some general consensus that some people would like to be
able to short-circuit functions like grep. Do you see no need for the code
block equivalent of Cnext/Clast/Credo?
sub mygrep (@) { ... }
@results = mygrep { $_ == 1 } (1..1_000_000);
How would you do it with out exceptions?
People have been quick to shoot down the various proposals for a standard
mechanism to short-circuit built-in and user-defined subroutines. Is this
because it shouldn't be done... or do people just not like ideas being
proposed to do it?
Garrett
P.S. I'm curious. is the Creturn control implemented as macro for throwing
an exception that is caught and handled by a subroutine? I.e., is there a
parallel between how Cnext/Clast/Credo and Creturn are implemented?
Re: $a in @b (RFC 199)
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Jarkko Hietaniemi
I find this urge to push exceptions everywhere quite sad.
Rather.
Languages that have forgotten or dismissed error returns, turning
instead to exceptions for everything in an effort to make the code
"safer", tend in fact to produce code that is tedious and annoying.
There seems to be some general consensus that some people would like to be
able to short-circuit functions like grep. Do you see no need for the code
block equivalent of Cnext/Clast/Credo?
What, you mean like
Loop controls don't work in an Cif or Cunless, either, since
those aren't loops. But you can always introduce an extra set
of braces to give yourself a bare block, which Idoes count
as a loop.
if (/pattern/) {{
last if /alpha/;
last if /beta/;
last if /gamma/;
# do something here only if still in if()
}}
--tom
RE: $a in @b (RFC 199)
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Garrett Goebel
There seems to be some general consensus that some people
would like to be able to short-circuit functions like
grep. Do you see no need for the code
block equivalent of Cnext/Clast/Credo?
What, you mean like
Loop controls don't work in an Cif or Cunless, either, since
those aren't loops. But you can always introduce an extra set
of braces to give yourself a bare block, which Idoes count
as a loop.
if (/pattern/) {{
last if /alpha/;
last if /beta/;
last if /gamma/;
# do something here only if still in if()
}}
Totally accurate, but it still doesn't allow me to short-circuit Cgrep and
return a value.
The only way I know to do that currently requires:
eval { grep { $_ ==1 and die "$_\n" } (1..1_000_000) };
chomp($@);
my $found = $@;
Re: $a in @b (RFC 199)
I find this urge to push exceptions everywhere quite sad. Rather. Languages that have forgotten or dismissed error returns, turning instead to exceptions for everything in an effort to make the code "safer", tend in fact to produce code that is tedious and annoying. Read the new KP: "failing to open a file is *not* an exceptional occurrence" (paraphrased from memory). --tom
Re: $a in @b (RFC 199)
David L. Nicol wrote: This ability to jump to "the right place" is exactly what exception handling is for, as I understand it. Exceptions allow us to have one kind of block and any number of kinds of exit mechanisms. If qC(last die return) are all excpetions, the can travel up the call stack until they find the appropriate handler. Kinda. "Exceptions" are supposed to be for exceptional situations only; return is none such. last/next/redo isn't really, either. And I strongly oppose having perl handle user-raised exceptions. But the "longjump" idea is right; so I propose that we lump these things together not as "exceptions" (though they may be implemented internally that way), but as "jumps". But I think the point is important, that the various kinds of blocks, and their respective, yea, defining, exit mechanisms, not be confused or conflated. We just need to clear up what kind of block grep/map use: either a true sub (which I favor), or a distinct kind, with its own early exit keyword(s). -- John Porter We're building the house of the future together.
Re: $a in @b (RFC 199)
'John Porter' wrote:
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
In the odd parallel universe where most perl 6 flow control is handled
by the throwing and catching of exceptions, the next/last/redo controls
are macros for throwing next/last/redo exceptions. Loop control
structures catch these objects and throw them again
if they are labeled and the label does not match a label the loop control
structure recognizes as its own.
...
In a nutshell, there are different kinds of blocks, and their
escape mechanisms are triggered by different keywords.
By unifying the block types, and making the keywords work across
all of them, I'm afraid we would lose this ability to jump up
through the layers of scope to "the right place".
This ability to jump to "the right place" is exactly what exception handling
is for, as I understand it. Exceptions allow us to have one kind of block
and any number of kinds of exit mechanisms. If qC(last die return) are all
excpetions, the can travel up the call stack until they find the appropriate handler.
The "traveling up the call stack" can even be optimized to a per-thread table of
what the appropriate handler is for the most commonly used types.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
Re: $a in @b (RFC 199)
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
In the odd parallel universe where most perl 6 flow control is handled
by the throwing and catching of exceptions, the next/last/redo controls
are macros for throwing next/last/redo exceptions. Loop control
structures catch these objects and throw them again
if they are labeled and the label does not match a label the loop control
structure recognizes as its own.
The more I think about this, and about why I like the way perl does
it currently, the more I think it would be a Bad Idea to unify the
various block types as I (and others) have previously suggested.
And it all boils down to the scope of returns, including non-local
returns (last and die).
It is hard to argue that perl's current setup is not powerful.
sub foo {
eval {
for (...) {
# all these go to different places:
last;
die;
return;
}
};
}
sub foo {
# and these as well:
last;
die;
return;
}
for (...) {
eval {
foo();
};
}
to give but two possible combinations.
In a nutshell, there are different kinds of blocks, and their
escape mechanisms are triggered by different keywords.
By unifying the block types, and making the keywords work across
all of them, I'm afraid we would lose this ability to jump up
through the layers of scope to "the right place".
The issue we've been struggling with is essentially the fact that
map/grep blocks don't have a similar early-exit mechanism.
One approach is to make them the same as one of our other block
types (sub, loop, eval); another is to add a new keyword to
implement the early exit.
Most folks seem to think that a grep block is more like a loop
block, and so want to use Clast; I have been more of the
opinion that a grep block is more like a sub, and so should use
Creturn. In the other camp, Cyield has been suggested; but
the conflation of that with its thread-related semantics may not
be a such good idea.
--
John Porter
We're building the house of the future together.
Re: $a in @b (RFC 199)
David L. Nicol wrote: "Randal L. Schwartz" wrote: I think we need a distinction between "looping" blocks and "non-looping" blocks. And further, it still makes sense to distinguish "blocks that return values" (like subroutines and map/grep blocks) from either of those. But I'll need further time to process your proposal to see the counterarguments now. In the odd parallel universe where most perl 6 flow control is handled by the throwing and catching of exceptions, the next/last/redo controls are macros for throwing next/last/redo exceptions. Loop control structures catch these objects and throw them again if they are labeled and the label does not match a label the loop control structure recognizes as its own. I find this urge to push exceptions everywhere quite sad. Most folks seem to think that a grep block is more like a loop block, and so want to use Clast; I have been more of the opinion that a grep block is more like a sub, and so should use Creturn. In the other camp, Cyield has been suggested; but the conflation of that with its thread-related semantics may not be a such good idea. Cpass. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: $a in @b (RFC 199)
Jarkko Hietaniemi wrote: In the other camp, Cyield has been suggested; but the conflation of that with its thread-related semantics may not be a such good idea. Cpass. Well, "pass" might be o.k.; but it usually means something going *into* a sub, not coming out... -- John Porter
Re: $a in @b (RFC 199)
On Thu, Sep 14, 2000 at 11:46:31AM -0400, 'John Porter' wrote: Jarkko Hietaniemi wrote: In the other camp, Cyield has been suggested; but the conflation of that with its thread-related semantics may not be a such good idea. Cpass. Well, "pass" might be o.k.; but it usually means something going *into* a sub, not coming out... I'll pass that remark. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: $a in @b (RFC 199)
David L. Nicol wrote: This ability to jump to "the right place" is exactly what exception handling is for, as I understand it. Exceptions allow us to have one kind of block and any number of kinds of exit mechanisms. If qC(last die return) are all excpetions, the can travel up the call stack until they find the appropriate handler. Kinda. "Exceptions" are supposed to be for exceptional situations only; return is none such. last/next/redo isn't really, either. And I strongly oppose having perl handle user-raised exceptions. But the "longjump" idea is right; so I propose that we lump these things together not as "exceptions" (though they may be implemented internally that way), but as "jumps". But I think the point is important, that the various kinds of blocks, and their respective, yea, defining, exit mechanisms, not be confused or conflated. We just need to clear up what kind of block grep/map use: either a true sub (which I favor), or a distinct kind, with its own early exit keyword(s). -- John Porter We're building the house of the future together.
Re: $a in @b (RFC 199)
'John Porter' wrote:
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
In the odd parallel universe where most perl 6 flow control is handled
by the throwing and catching of exceptions, the next/last/redo controls
are macros for throwing next/last/redo exceptions. Loop control
structures catch these objects and throw them again
if they are labeled and the label does not match a label the loop control
structure recognizes as its own.
...
In a nutshell, there are different kinds of blocks, and their
escape mechanisms are triggered by different keywords.
By unifying the block types, and making the keywords work across
all of them, I'm afraid we would lose this ability to jump up
through the layers of scope to "the right place".
This ability to jump to "the right place" is exactly what exception handling
is for, as I understand it. Exceptions allow us to have one kind of block
and any number of kinds of exit mechanisms. If qC(last die return) are all
excpetions, the can travel up the call stack until they find the appropriate handler.
The "traveling up the call stack" can even be optimized to a per-thread table of
what the appropriate handler is for the most commonly used types.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
RE: $a in @b (RFC 199)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Garrett Goebel [EMAIL PROTECTED] writes:
I agree... why can't a block be a block? Or put another
way, instead of trying to shoehorn in something new, why
don't we take away something old and treat all the blocks
the same under Perl 6?
You mean this would no longer work?
while () {
if ($some_condition) {
fred fred fred;
next;
}
barney barney barney;
}
With my current proposal, you're right... if you wrote that in Perl 6, it
wouldn't work the way you're wanting...
So yes... this is starting to feel a little bit more like a shoehorn. Can I
extricate myself by wedging one more thing in?
When you call Cnext, Clast, or Credo without an explicit label, then
it defaults per current behaviour to the nearest loop block. So if you wish
to short-circuit a code block or a bare block... they'd have to be labelled
and short-circuited explicitly.
Nope, I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
Yes... loop blocks are special in that short-circuiting the looping block
short-circuits the loop, not just the block. Perhaps we could maintain that
as the default behaviour but otherwise blur the line by allowing all blocks
to Creturn, Cyield, Cnext, Clast, Credo, and return last values?
I'm not sure why we need to distinguish blocks that return values from those
that don't. But I'm not nearly as experienced or knowledgible about these
things as 99% of the people on this list. And I have a harder time seeing
the impact of my suggestions.
What is the difference between a block returning a value in a void context,
and one that doesn't? I suppose this introduces a new way to create runtime
exceptions by short-circuiting a subroutine without returning a value when
that subroutine is being used to provide a value for an lvalue assignment.
I would also like to thank everyone for their patience and civility when
responding to my posts. I'm trying to read up and get a better grasp of the
fine details... but I'm still learning a lot as I go. And I'm a lot further
back on the path to Perl enlightenment than most here. When it appears I'm
off in left field... I probably am ;) In such cases, please take the time
to kindly nudge me back in the direction of reality.
Garrett
Re: $a in @b (RFC 199)
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
In the odd parallel universe where most perl 6 flow control is handled
by the throwing and catching of exceptions, the next/last/redo controls
are macros for throwing next/last/redo exceptions. Loop control
structures catch these objects and throw them again
if they are labeled and the label does not match a label the loop control
structure recognizes as its own.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 04:41:29PM -0500, Jarkko Hietaniemi wrote: Allow me to repeat: instead of trying to shoehorn (or piledrive) new semantics onto existing keywords/syntax, let's create something new. The blocks of grep/map/... are special. They are not quite looping blocks, they are not quite sub blocks, they are different. Well, to be frank they are just very plain, ordinary, blocks that return their last value, but if we want to introduce both flow control (short-circuiting) and as a derived requirement, a return value (was the last test a success or a failure), they definitely begin to become not your ordinary blocks. I do not think the existing arsenal of keywords/syntax is enough to cover all the behaviour we are after. The 'pass' keyword someone suggested has potential (when combined with allowing last -- and next -- to work on these mongrel blocks). Also it should be possible for someone to write thier own looping construct like map/grep as a sub and take advantage of this. Graham.
Re: $a in @b
At 09:37 AM 9/12/00 -0400, Jerrad Pierce wrote:
Doh! perhaps then more like:
#grep for str's beginning and ending in a digit
grep ITEM: { /^[1-9]/; next ITEM unless /[1-9]$/ } @list;
Of course there are other ways of writing this...
Are there any cases people want this for that CANNOT be rewritten?
Or is it purely syntactic sugar? Not that that is a bad thing,
as I've mentioned I think a way to short-circuit/bypass/"return" from
an otherwise undistinguished block would be nice. There have been
many times I've wanted to do same.
I think it's fine to allow a loop label on the grep block, but it wasn't
really what I thought we were discussing; you still haven't indicated what
the value of the block should be on that iteration. undef is a reasonable
default but how to provide another? That's what my idea was, to provide a
second argument. Also, shouldn't be necessary to label a loop if you don't
have another one inside it, although if you did, it would avoid the
embarrassment of "last undef, 'foo'" that fell out of my suggestion.
--
Peter Scott
Pacific Systems Design Technologies
Re: $a in @b (RFC 199)
Jarkko Hietaniemi wrote:
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return their
last value, but if we want to introduce both flow control
So, why not get rid of the specialness? Why can't all blocks return
their last value? The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for the value
to go doesn't mean they can't return a value.) And if that's done, then
$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;
might not be a horrible idea either.
Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort, and would be
extended to specify the value returned. 'last $value' would be
equivalent to 'return $value' inside a subroutine unless it were
enclosed in a loop BLOCK.
Extension idea: just use last LABEL, $value:
last LABEL = $value
or
last = $value
(last, $value seems like it wouldn't be terribly useful otherwise,
right?)
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
What am I missing?
Re: $a in @b (RFC 199)
Steve Fink wrote:
So, why not get rid of the specialness? Why can't all blocks return
their last value?
Then we would have sub BLOCKs and loop BLOCKs. 'return' would escape the
nearest enclosing sub BLOCK and return a value. last/redo/next would
escape/repeat/continue the enclosing BLOCK of any sort...
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
I think any block which currently can "return" a value by letting it
fall out the end should be able to return a value by using Creturn
explicitly. I can count how many times I've wanted to -- and thought
I should be able to -- do something like the following:
@x = map {
/:/ and return( $`, $' );
/,/ and return( $`, $' );
()
} @y;
O.k., ignore the stupidness of the example. Point is, I can't
return a value "early" from the loop.
--
John Porter
We're building the house of the future together.
Re: $a in @b
"Randal L. Schwartz" wrote:
how do you indicate with 'last' that you
want a false return, or a true return? This never comes up with a do
{} block, or a subroutine block, because while those are being
evaluated for a value, they don't respect last/next/redo.
if "last" means, return the most recently evaluated expression as
a return value and do not re-enter the block, the various semantics
can be created with a comma.
Your
request to have the grep block understand 'last' was the first block
in Perl history that would have simultaneously needed to exit early
*with* a value. And we hadn't come around that block yet. :)
We really need a clean way to distinguish those four cases:
"yes" and keep going
"no" and keep going
"yes" and abort after this one
($FirstSmall) = grep { $_ = 7 and last } @numbers; # already true
"no" and abort after this one
my $count;
# minor chicanery required to force short-circuit with false result
@Smalls_in_first_five =
grep { $count++ 5 ? ($_ = 7) : (0,last)} @numbers;
I see Clast in grep/map as implicitly setting a gatekeeping variable which
would prevent the remainder of the data from being evaluated. Since this is
known, evaluation of the remainder of the data can be safely optimised away.
Using the "gatekeeper" idea without Clast we get these:
"yes" and abort after this one
my $gatekeeper = 1;
($FirstSmall) = grep
{ $gatekeeper and $_ = 7 and ($gatekeeper = 0), 1 } @numbers;
"no" and abort after this one
my $count;
my $gk = 1;
@smalls_in_first_five = grep
{$gk and ($count++ 5 ? ($_ = 7) : $gk=0 )} @numbers;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox
RE: $a in @b (RFC 199)
From: Steve Fink [mailto:[EMAIL PROTECTED]]
Jarkko Hietaniemi wrote:
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return
their last value, but if we want to introduce both flow control
So, why not get rid of the specialness? Why can't all blocks return
their last value?
Yes... why not?
The ones that currently do not return a value would
just be given void context. (Just because there's nowhere for
the value to go doesn't mean they can't return a value.) And if
that's done, then
$val = 1;
$fact = while ($n) { $val *= $n--; } || $val;
might not be a horrible idea either.
Then we would have sub BLOCKs and loop BLOCKs. 'return' would
escape the nearest enclosing sub BLOCK and return a value.
last/redo/next would escape/repeat/continue the enclosing BLOCK
of any sort, and would be extended to specify the value
returned. 'last $value' would be equivalent to 'return $value'
inside a subroutine unless it were enclosed in a loop BLOCK.
I agree... why can't a block be a block? Or put another way, instead of
trying to shoehorn in something new, why don't we take away something old
and treat all the blocks the same under Perl 6? I.e, make loop, bare, and
code blocks able to Creturn, Cyield, Cnext, Clast, and Credo? And
make all blocks that haven't been short-circuited to return their last
value...
That would unify bare and code blocks. They'd be like an iterative loop that
executes once and allows a return value.
But loop blocks are still different. When you use a loop control statement
(Cnext, Clast, or Credo) in a loop block, you don't short-circuit the
loop block, you short-circuit the loop statement.
Since blocks can have labels, how about giving built-in functions and
user-defined subroutines their own name as a magic or default label? I know
labels currently can't have package qualifiers. So perhaps this will
conflict with some interals issue. Or maybe it doesn't matter. In any case,
this will leave the programmer some freedom as to whether they are
short-circuiting the block, the loop, or the user-defined function.
Combine the unification of blocks with Tom Christiansen's suggestion which
maintains DWIMish syntax (and doesn't feel like a shoehorn to me at least):
return $true next;
return $false next;
return $true last;
return $false last;
return $true redo;
return $false redo;
Bonus: I no longer have to care about the difference between "code", "loop",
and "bare" blocks...
Here's an user-defined grep subroutine using the proposed changes:
sub mygrep (@) {
my ($block, @list, @results) = @_;
push @results, LOOP: $block and $_ foreach (@list);
@results
}
@list = (1,2,3,2,1);
@a = mygrep { $_ = 2 or last} @list;
@b = mygrep { $_ = 2 or last LOOP} @list;
@c = mygrep { $_ = 2 or last mygrep} @list;
@d = mygrep { $_ = 2 or return $_ last} @list;
@e = mygrep { $_ = 2 or return $_ last LOOP} @list;
@f = mygrep { $_ = 2 or return $_ last mygrep} @list;
Resulting I would hope in:
@a = (1 2 2 1)
@b = (1 2)
@c = [exception]
@d = (1 2 3 2 1)
@e = (1 2 3)
@f = (3)
Oh yeah. do BLOCK is still a third kind, which is transparent to all
control constructs.
The Cdo block is really more like special anonymous subroutine that takes
no arguments and is special in the sense that it is evaluated before the
loop condition of Cwhile and Cuntil. I have no idea why it is evaluated
before the loop condition... That seems un-DWIMish.
Garrett
Re: $a in @b (RFC 199)
"Garrett" == Garrett Goebel [EMAIL PROTECTED] writes:
Garrett I agree... why can't a block be a block? Or put another way, instead of
Garrett trying to shoehorn in something new, why don't we take away something old
Garrett and treat all the blocks the same under Perl 6?
You mean this would no longer work?
while () {
if ($some_condition) {
fred fred fred;
next;
}
barney barney barney;
}
Yup. Sure looks like a block to me. If "next" aborts only the "if"
block, but still executes barney barney, then it's now useless for
about 70% of my usage of "next".
Nope, I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need further time to process
your proposal to see the counterarguments now.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: $a in @b
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes: RLS We really need a clean way to distinguish those four cases: RLS "yes" and keep going RLS "no" and keep going RLS "yes" and abort after this one RLS "no" and abort after this one RLS What would you have "last" do? And how would you distinguish "the RLS other one"? Either last has to be extended with a return value or a new keyword is needed. I'm quite partial to yield. Which might be overloaded to work with lazy lists, continuations, and short-circuiting. yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
Chaim Frenkel [EMAIL PROTECTED] writes: "RLS" == Randal L Schwartz [EMAIL PROTECTED] writes: RLS We really need a clean way to distinguish those four cases: RLS "yes" and keep going RLS "no" and keep going RLS "yes" and abort after this one RLS "no" and abort after this one RLS What would you have "last" do? And how would you distinguish "the RLS other one"? Either last has to be extended with a return value or a new keyword is needed. I'm quite partial to yield. Which might be overloaded to work with lazy lists, continuations, and short-circuiting. yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. When you put it this way, isn't Cyield spelled Creturn in Perl5? (Except, of course, that Creturn inside a Cgrep does a whole lot more nowadays). -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: $a in @b
Randal Schwartz wrote:
We really need a clean way to distinguish those four cases:
"yes" and keep going
"no" and keep going
"yes" and abort after this one
"no" and abort after this one
What would you have "last" do? And how would you distinguish "the
other one"?
Sounds like people are trying to fit two booleans into one expression.
Probably what is needed is for grep to have two control expressions:
one to determine whether each element is selected to be put into the
output list (grep's current boolean expression), and one to determine
whether grep should continue execution.
Perhaps a new "pass" keyword should be added, which passes the
current list element through the filter.
@L = (1, 2, 3, 10, 3, 2, 1);
@l = grep {pass if $_1; last if $_9} @L;#-- (2, 3, 10)
@l = grep {last if $_9; pass if $_1} @L;#-- (2, 3)
@l = grep {pass if $_1; next if $_9} @L;#-- (2, 3, 10, 3, 2)
@l = grep {next if $_9; pass if $_1} @L;#-- (2, 3, 3, 2)
A grep block with no explicit 'pass' would pass if the last expression
in the block evaluates to true, just as grep does now:
@l = grep {$_9} @L; # same as:
@l = grep {pass if $_9}; #-- (10)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: $a in @b
"Ariel" == Ariel Scolnicov [EMAIL PROTECTED] writes:
yield EXPR - stop what I am doing now and give something else a
a chance to do its things. And while you are doing
that please take this EXPR from me.
Ariel When you put it this way, isn't Cyield spelled Creturn in Perl5?
Ariel (Except, of course, that Creturn inside a Cgrep does a whole lot
Ariel more nowadays).
Yes, I'd be in favor of making return() in a valued block (as opposed
to a looping block) abort the block early and return the value. I
don't think I'd want to change last() to do that, since last() already
has an optional parameter (the loop label). That makes the valued
block of a do {} or a grep or map be able to abort with a particular
value. Although it would break any use of return in those blocks to
abort the enclosing subroutine, and there wouldn't be any clean
translation available. Ugh. Maybe we do need a new keyword. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: $a in @b
Ariel Scolnicov wrote: Chaim Frenkel [EMAIL PROTECTED] writes: yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. When you put it this way, isn't Cyield spelled Creturn in Perl5? (Except, of course, that Creturn inside a Cgrep does a whole lot more nowadays). And except that Cyield allows you to pick up where you left off later, at least per Damian's RFC 31: "Co-routines". For a grep/map this could potentially be really useful, especially if you have code that modifies values in your block but want to do it conditionally/iteratively. -Nate
Re: $a in @b
Randal L. Schwartz wrote:
We really need a clean way to distinguish those four cases:
"yes" and keep going
"no" and keep going
"yes" and abort after this one
"no" and abort after this one
What would you have "last" do? And how would you distinguish "the
other one"?
This is my suggestion: the only effect of "last" should be to signal
to the grep not to iterate further; and, as with the current sitch,
whatever the last evaluated value in the block would be the "returned"
value. So to effect the above, you would do the following:
Just as with the current implementation:
"yes" and keep going: grep { ... 1 } @a;
"no" and keep going: grep { ... 0 } @a;
Exercising the new feature:
"yes" and abort after this one: grep { ... 1, last } @a;
"no" and abort after this one: grep { ... 0, last } @a;
Of course, "last" would have to be ignored in the algorithm which
determines the "last evaluated value"...
--
John Porter
We're building the house of the future together.
Re: $a in @b
Ariel Scolnicov wrote: When you put it this way, isn't Cyield spelled Creturn in Perl5? (Except, of course, that Creturn inside a Cgrep does a whole lot more nowadays). Hopefully, what Creturn does in grep in perl6 will be different from perl5. -- John Porter We're building the house of the future together.
Re: $a in @b
Randal L. Schwartz wrote: Yes, I'd be in favor of making return() in a valued block (as opposed to a looping block) abort the block early and return the value. Imho, it should return the value, but not abort the block. That's not very dwimmy. Loop blocks look like sub blocks to me. After all, grep is (ostensibly) prototyped as grep(@), so I expect to pass it a sub block. And that block gets called once per iteration over the input list; "return" is what I expect it to do once per iteration, implicitly; so using Creturn explicitly to mean "no further iterations" is highly counterintuitive, or at least inconsistent. -- John Porter We're building the house of the future together.
Re: $a in @b
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: AS Chaim Frenkel [EMAIL PROTECTED] writes: yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. AS When you put it this way, isn't Cyield spelled Creturn in Perl5? AS (Except, of course, that Creturn inside a Cgrep does a whole lot AS more nowadays). Err, no. return is much stronger. It goes to the caller of the sub. Yield would be relative to a much tighter scope. I think Randal would reject this, but if we make it an error to have a last/next/redo reach outside of a visible lexical scope, then last,next,redo would be 'weakest', followed by yield, return, die (and whatever is used for exceptions.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
I don't want 'return' to have any meaning other than returning from a
subroutine, nor do I want the word 'goto' to appear in my code except for
goto sub.
How about we just allow last, redo, next to take another argument, which
provides the final or intermediate value of a block whose value is being
used? First argument can be undef for nearest enclosing block. Yes, it
looks a little weird, but this is a relatively uncommon thing to want to do
and not worth IMHO creating a new keyword for, so why shouldn't it look
weird. Hence:
$foo = do { last undef, $bar if baz($bar) } while $bar++;
@list = grep { last undef, '' if /sentinel/; baz($_) } @thingies;
@list = grep { next undef, 'okay' if /sentinel/; baz($_) } @thingies;
etc. I'm assuming that one would want to retain the capability to last,
next etc out of an outer enclosing labelled loop, otherwise I'd just
propose overloading the one argument and say that if it's a reference, take
the thing it refers to as the value and exit/continue the nearest enclosing
loop.
--
Peter Scott
Pacific Systems Design Technologies
RE: $a in @b
From: Peter Scott [mailto:[EMAIL PROTECTED]]
I don't want 'return' to have any meaning other than returning from a
subroutine
Which it wouldn't since the {} block in grep is a code block ;)
Garrett
RE: $a in @b (RFC 199)
From: John Porter [mailto:[EMAIL PROTECTED]]
Randal L. Schwartz wrote:
Yes, I'd be in favor of making return() in a valued block
(as opposed to a looping block) abort the block early and
return the value.
Imho, it should return the value, but not abort the block.
I.e. stick with the current behaviour. -Yes, I'd be surprised if
sub mygrep (@) {
my ($coderef, @list, @stack) = @_;
$coderef and push(@stack, $_) foreach (@list);
return @stack;
}
@a = mygrep { return ($_ = 2) ? 1 : 0 } (1, 2, 3, 2, 1);
print "\@a = @a\n";
Resulted in: @a =
Instead of the current Perl 5: @a = 1 2 2 1
After all, grep is (ostensibly) prototyped as grep(@), so I
expect to pass it a sub block. And that block gets called
once per iteration over the input list; "return" is what I
expect it to do once per iteration, implicitly; so using
Creturn explicitly to mean "no further iterations" is highly
counterintuitive, or at least inconsistent.
RE: $a in @b (RFC 199)
From: Nathan Wiger [mailto:[EMAIL PROTECTED]]
Ariel Scolnicov wrote:
Chaim Frenkel [EMAIL PROTECTED] writes:
yield EXPR - stop what I am doing now and give something else a
a chance to do its things. And while you are doing
that please take this EXPR from me.
When you put it this way, isn't Cyield spelled Creturn in Perl5?
(Except, of course, that Creturn inside a Cgrep does a whole lot
more nowadays).
And except that Cyield allows you to pick up where you left
off later, at least per Damian's RFC 31: "Co-routines". For a
grep/map this could potentially be really useful, especially
if you have code that modifies values in your block but want
to do it conditionally/iteratively.
I wouldn't argue that Cyield would be a useful in the context of Cgrep
and Cmap. But it doesn't solve the problem (RFC 199) of short-circuiting
Cgrep and Cmap if you have no intention of preserving state.
grep { 1 } 1..1_000_000;
Garrett
Re: $a in @b (RFC 199)
Garrett Goebel wrote:
I'd be surprised if
sub mygrep (@) {
my ($coderef, @list, @stack) = @_;
$coderef and push(@stack, $_) foreach (@list);
return @stack;
}
@a = mygrep { return ($_ = 2) ? 1 : 0 } (1, 2, 3, 2, 1);
print "\@a = @a\n";
Resulted in: @a =
Instead of the current Perl 5: @a = 1 2 2 1
Yes! *Exactly* my point! Blocks should quack the same whether
I pass them to the built-in grep or to my own sub; i.e. they're
anonymous subs, not some magico-special "looping" blocks.
--
John Porter
We're building the house of the future together.
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 05:31:33PM -0400, 'John Porter' wrote:
Garrett Goebel wrote:
I'd be surprised if
sub mygrep (@) {
my ($coderef, @list, @stack) = @_;
$coderef and push(@stack, $_) foreach (@list);
return @stack;
}
@a = mygrep { return ($_ = 2) ? 1 : 0 } (1, 2, 3, 2, 1);
print "\@a = @a\n";
Resulted in: @a =
Instead of the current Perl 5: @a = 1 2 2 1
Yes! *Exactly* my point! Blocks should quack the same whether
I pass them to the built-in grep or to my own sub; i.e. they're
anonymous subs, not some magico-special "looping" blocks.
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return their
last value, but if we want to introduce both flow control
(short-circuiting) and as a derived requirement, a return value
(was the last test a success or a failure), they definitely begin to
become not your ordinary blocks. I do not think the existing arsenal
of keywords/syntax is enough to cover all the behaviour we are after.
The 'pass' keyword someone suggested has potential (when combined with
allowing last -- and next -- to work on these mongrel blocks).
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: $a in @b
DC I would propose that the Cgrep operation should short-circuit if the DC block throws an exception, with the value of the expection determining DC whether the final invocation of the block should accept the element it DC was filtering: Why not spell it 'yield'? It seems to have all the right connotations. A sort of soft return. Gives of itself. Very polite. :-) I did consider that too, but the problem is that according to RFC 31 a Cyield leaves the future entry point of a block at the next statement after the Cyield, whereas the block needs to start from the beginning on each iteration. Damian
Re: $a in @b
Either last has to be extended with a return value or a new keyword is needed. I'm quite partial to yield. Which might be overloaded to work with lazy lists, continuations, and short-circuiting. yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. The problem is, Cyield also means "..and when this code is next executed start at the line after this Cyield". Which is *not* the desired semantics. Damian
Re: $a in @b
Pardon my repetitiousness, but I'm puzzled at the total lack of response AFAICS to my proposal for a second argument to next/last/redo. Was it so stupendously moronic as to be beneath anyone's dignity to rebut, or what? Either I'm out of it, or it looks a whole lot more appealing than a new keyword. $0.02. -- Peter Scott Pacific Systems Design Technologies
Re: $a in @b
Pardon my repetitiousness, but I'm puzzled at the total lack of response
AFAICS to my proposal for a second argument to next/last/redo. Was it so
stupendously moronic as to be beneath anyone's dignity to rebut, or
what? Either I'm out of it, or it looks a whole lot more appealing than a
new keyword.
IMHO THAT (two args) would be overkill. These are operators, simple flow
control words that also make the source very easy to read.
i really can;t see adding a second arg because ythen you're going to have
to do stuff like
next undef, 1
etc. which is wholly unappetizing. The only way I myself see extending
current words is to use some special label name. not that that is very nice...
Only if this special name perhaps contained a character which is not valid in
a label... (are there any? [:*] ?)
I personally like the idea of somehting like feign (or whatever it's called),
nice and generic. But if not that and not 2 arg next etc. And I may have
missed this thread if someone hit upon it, but what's wrong with
allowing something like
grep ITEM: { /^[1-9]/ || next ITEM } @list;
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj tb.";{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}v;}{$_++;$_--;$_||=4;
if($_2||($_212)){$_="Vainyvq ragel";{$F[0]};last;}t;$0-=$_;$_="Lbh jva";
die({$F[0]}) if !($0-1);$0-=$0%2?$02?2:1:$0=5?$02?3:1:rand.5?1:3;
$_="V jva";die({$F[0]}) if !($0-11);}v __END__ http://pthbb.org/
MOTD on Prickle-Prickle, the 35th of Bureaucracy, in the YOLD 3166:
Were that I say, pancakes? --JP
Re: $a in @b
At 09:45 PM 9/11/00 -0400, Jerrad Pierce wrote:
Pardon my repetitiousness, but I'm puzzled at the total lack of response
AFAICS to my proposal for a second argument to next/last/redo. Was it so
stupendously moronic as to be beneath anyone's dignity to rebut, or
what? Either I'm out of it, or it looks a whole lot more appealing than a
new keyword.
IMHO THAT (two args) would be overkill. These are operators, simple flow
control words that also make the source very easy to read.
i really can;t see adding a second arg because ythen you're going to have
to do stuff like
next undef, 1
etc. which is wholly unappetizing.
Well, it's hard to argue matters of taste. All I'll say is that the
capability we're discussing will be so rarely used IMHO that expending a
new keyword for its sake isn't worth it. Keywords exact a high price in
namespace pollution and user brain cells. I know it's debatable whether it
uses any more brain cells than an extra argument to next, but I happen to
find it a bit more intuitive. There again, I would :-)
The only way I myself see extending
current words is to use some special label name. not that that is very nice...
Only if this special name perhaps contained a character which is not valid in
a label... (are there any? [:*] ?)
I personally like the idea of somehting like feign (or whatever it's called),
nice and generic. But if not that and not 2 arg next etc. And I may have
missed this thread if someone hit upon it, but what's wrong with
allowing something like
grep ITEM: { /^[1-9]/ || next ITEM } @list;
Not much that I can see, but your next does not include any return value,
so what should it be? Of course, if it's false, you didn't need a next in
the first place and if it's true you didn't need a grep in the first place :-)
--
Peter Scott
Pacific Systems Design Technologies
Re: $a in @b
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
TC I never did figure out why "last" {w,sh,c}ouldn't be made to do
TC that very thing.
Hey, I suggested that a while ago, but Randal shot it down.
Something about the block not being a loop, I think.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I would propose that the Cgrep operation should short-circuit if the DC block throws an exception, with the value of the expection determining DC whether the final invocation of the block should accept the element it DC was filtering: Why not spell it 'yield'? It seems to have all the right connotations. A sort of soft return. Gives of itself. Very polite. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
TC I never did figure out why "last" {w,sh,c}ouldn't be made to do
TC that very thing.
Chaim Hey, I suggested that a while ago, but Randal shot it down.
Chaim Something about the block not being a loop, I think.
I think it was more along the lines that Damian (I think) enumerated
of "what value does a block being evaluated for a value but exited
with 'last' return?". As in, how do you indicate with 'last' that you
want a false return, or a true return? This never comes up with a do
{} block, or a subroutine block, because while those are being
evaluated for a value, they don't respect last/next/redo. Your
request to have the grep block understand 'last' was the first block
in Perl history that would have simultaneously needed to exit early
*with* a value. And we hadn't come around that block yet. :)
We really need a clean way to distinguish those four cases:
"yes" and keep going
"no" and keep going
"yes" and abort after this one
"no" and abort after this one
What would you have "last" do? And how would you distinguish "the
other one"?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: $a in @b
Damian Conway wrote:
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 Cand and Clast.
No, only Clast... and I think we're preparing to do that anyway, right?
Let's take a step back and analyse the problem. We need a way to allow a
...
*and* be consistent with existing semantics.
If feasible. Not otherwise.
I would propose that the Cgrep 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:
Oh, no. perl catches user-thrown exceptions and attaches special semantics
to the exception value? That's a horrendous idea, completely unprecedented
in Perl. User-thrown exceptions should longjump directly to the enclosing
user-defined try block, nothing else.
What you're proposing to do with exceptions, I'm proposing to do with last.
I.e. your C die 'foo'; would be my C 'foo'; last; ;
--
John Porter
We're building the house of the future together.
Re: $a in @b
David L. Nicol wrote: I'd like to see next/last/redo in such situations pertain to the block from which the sub was called, if that makes sense. Well, that's the behavior in perl5. Most people don't know about it, and those who do think it's bizarre. It's perl's secret action at a distance. -- John Porter We're building the house of the future together.
RE: $a in @b
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 the Clast is
executed, which terminates the Cgrep immediately.
instead of the current behaviour which would be
@passed = (1, 2, 2, 1)
That's not the current behaviour.
Yes, and my example was bad anyway. Sloppy, sloppy... What I
meant to write (which is still useless anyway) was:
@passed = grep { $_ 2 and last } (1, 2, 3, 2, 1);
^^
Under Perl 5...
With the Clast you either get an exception
Can't "last" outside a loop block at ...
Which is what I suppose we are proposing could be changed. Would that imply
that in Cmap, Cgrep, and Creduce the block be treated as a iterative
loop's block?
I have practically no knowledge of the Perl internals, implementation
details, or the specific terminology to use with regards to Perl internals.
I'm just an outsider looking in. Please correct my terminology if needed,
and feel free to suggestion ideas for implementation. I had the mistaken
impression, that this topic was easy enough that even I could fully grok it.
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting Creduce.
Hmm... what RFC 76 says is:
If the reduction subroutine is ever terminated by a call to Clast,
the enclosing Creduce immediately returns the last reduction value
(i.e. Cundef on the first reduction call, $_[0] otherwise)
Which I read to mean that Creduce would be treated as an iterative looping
construct?
Since only loops can be exited with Clast. Would that mean that:
Cgrep, Cmap, and Creduce would "be" iterative loops like Cwhile,
Cuntil, Cfor, and Cforeach... or would someone have to invent some new
internal representation for Clast to treat them as such?
or an exit from the surrounding block (and in either case
@passed is not reassigned at all).
Yes... I should have actually tried this before making up what I thought it
would be.
I suppose the fact that I inherently have a hard time shaking the assumption
that the blocks in Cgrep and Cmap should be treated as iterative
loops... is a vote in favor of allowing one to think of them as such. After
all, they are iteratively looping through a list of elements... What am I
missing here? How is this different than Cfor and Cforeach other than
syntax? Is there any history behind why they aren't already iterative loops?
We are already advised not to use last within eval {}, sub {},
do {}, grep {}, and map {}, but this might break some
obfuscated code which depends on it. I'm not to sure how
this could be handled in a Perl 5-6 translation...
Have p52p6 name *every* block and label *every* Cnext,
Clast, and Credo.
Okay, I wasn't sure it needed to go that far, but it is probably far easier
to implmement and more reliable. I'll update the RFC.
Now that I'm actually checking how the "advice" (Camel Book, 3rd Ed, pg 735,
Clast) is inforced by the interpreter... the results are as follows:
eval { last }; # [no error]
do { last }; # Can't "last" outside a loop block at
sub { last } # [no error]
grep { last } (1); # Can't "last" outside a loop block at
map { last } (1); # Can't "last" outside a loop block at
Garrett
Re: $a in @b
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 returned to grep()? If you use
0 as the last value evaluated inside the block, grep() would return an
empty list, 0 in scalar conetxt, and all your tests woukld be in vain.
So: should
scalar grep { 1 and last } LIST
return 1, if LIST is not empty, and
scalar grep { 0 or last } LIST
return 0?
If that is not dealt with, last inside a grep block will never work.
--
Bart.
Re: $a in @b
Garrett Goebel wrote:
Let's see if I've got this straight. To paraphrase Damian's
RFC 77 for reduce:
If a Cgrep's block were terminated by a call to Clast,
grep immediately returns the last block value (i.e. Cundef
on the first block call, $_[0] otherwise). Or maybe that's @_
otherwise...
No; I think you have it right down here:
The end result would be that if Clast occured the first time that
grep's block was evaluated, an empty list would be returned.
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 of all the
elements of @b that had passed through to that point.
Actually, that's what it would do regardless of the internal
implementation. Either way, the result (assigned to @a) is the
list of items which passed the condition, up to the point the
loop was terminated via "last".
So: should
scalar grep { 1 and last } LIST
return 1, if LIST is not empty,
Yes. The first item in LIST passed the condition,
and then the loop terminated.
scalar grep { 0 or last } LIST
return 0?
Yep.
These are scalar contexts; we're asking for the number of
items in the result.
--
John Porter
We're building the house of the future together.
Re: $a in @b
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
But it makes "short-circuit as soon as Cgrep
lets through a specific value" ugly:
my $seen;
$has_odd_elem = grep { $seen last; $_%2 ++$seen } @numbers;
Not just ugly. Useless.
--
Bart.
Re: $a in @b
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 Cgrep
lets through a specific value" ugly:
my $seen;
$has_odd_elem = grep { $seen last; $_%2 ++$seen } @numbers;
Not just ugly. Useless.
How about using 'return', then? That could, ahem, return both true and
false values. Yes, that does have semantics now...but can someone with
a straight face confess to having used that, e.g.
sub ... { ... grep { ... return; } ... }
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: $a in @b
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 eliminate the dichotomy:
allow next/last/redo to pertain to a subroutine. I.e. last would
exit the sub, and redo would be essentially equivalent to goto self;
The last-ness/next-ness of the sub return would be communicated to the
caller, in case it's interested (as grep would be).
Then grep blocks would simply be defined to be real subs.
grep { return /pat/ } @foo
would be the same as
grep { /pat/ } @foo
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
If the value of the test is wrong (and "not" won't do), the
return value can be set before the last:
grep { crud($_) and 0, last } @foo
# reject the item even though crud() returns true.
grep { crud($_) or 1, last } @foo
# accept the item even though crud() returns false.
--
John Porter
We're building the house of the future together.
Re: $a in @b
Damian Conway wrote:
The expression C1 and last does *not* evaluate to true -- it does not
evaluate to *anything*. So the Cgrep is terminated by the Clast
without the block having ever evaluated true. So no element of LIST is
ever "passed through". So the Cscalar grep evaluates to zero.
Right. Well, perl6 doesn't exist yet. See my other recent post for
a proposal on rectifying the semantics of sub return in the presence
of last.
To continue: last-ing/next-ing out of a sub allows the Last Evaluated
Value (as per current perl semantics) to be returned, and a special
flag is also returned to the caller indicating that last/next was used.
Functions such as foreach will discard the returned value, regardless,
but care about the next/last/redo flag; functions like grep mainly
care about the return value, but honor the "last" if present.
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
We're building the house of the future together.
Re: $a in @b
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 Cand and Clast.
Let's take a step back and analyse the problem. We need a way to allow a
Cgrep block to do all of the following:
* reject the current element and continue
* accept the current element and continue
* reject the current element and then short-circuit
* accept the current element and then short-circuit
*and* be consistent with existing semantics.
I would propose that the Cgrep 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:
# existing (non-short-circuiting) semantics...
@smalls = grep { ($_ 2) } @numbers;
# short-circuit after first acceptance...
@smalls = grep { ($_ 2) and die 1 } @numbers;
# short-circuit after first rejection...
@smalls = grep { ($_ 2) or die 0 } @numbers;
This would extend naturally to cater to Cmap and Creduce blocks, which
must return a value, rather than a flag:
# existing (non-short-circuiting) semantics...
@squares = map { $_ ** 2 } @numbers
$product = reduce { $_[0] * $_[1] } @numbers
# short-circuit after result reaches 100 (but include that result)...
@squares = map { my $sq = $_ ** 2; $sq = 100 ? die $sq : $sq }
@numbers;
$product = reduce { my $pr = $_[0] * $_[1]; $pr = 100 ? die $pr : $pr }
@numbers
# short-circuit when result reaches 100 (and exclude that result)...
@squares = map { my $sq = $_ ** 2; $sq = 100 ? die : $sq }
@numbers;
$product = reduce { my $pr = $_[0] * $_[1]; $pr = 100 ? die : $pr }
@numbers
I'll be happy to change the Creduce RFC if people like this alternative.
Damian
Re: $a in @b
I would propose that the Cgrep 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's being downgraded to "oh, well, never mind (the rest)" status... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: $a in @b
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 like to see next/last/redo in such situations pertain to the
block from which the sub was called, if that makes sense.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' /usr/dict/words
Re: $a in @b
Damian Conway wrote:
A Cgrep 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 stronger!)
it could be made weaker, so that "last" within the grep block
expands to
do {push @tmp, $_; last}
If BLOCK contained a Clast, the invocation of that Clast would
*immediately* cause the implicit Cforeach to terminate,
*without* pushing any value onto @tmp from the final execution of
the code in BLOCK.
That's not DWIM
That is not an onerous constraint on inequalities: vs = gives you
the control you need. But it makes "short-circuit as soon as Cgrep
lets through a specific value" ugly:
my $seen;
$has_odd_elem = grep { $seen last; $_%2 ++$seen } @numbers;
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
Cmap 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 subroutine.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=' /usr/dict/words
Re: $a in @b
On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote: I would propose that the Cgrep 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 don't think Cgrep 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? - Damien
Re: $a in @b
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 Cmap 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 subroutine. Maybe it's simply time to give up trying to bend existing semantics and think of a new flow control keyword? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: $a in @b
I don't think Cgrep 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
Re: $a in @b
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
Re: $a in @b
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 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: $a in @b
Jonas Liljegren wrote:
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
...
You could even use it as a version of the ||| operator. :-)
$a = in @b; # Assign the first defined value to $a
Quantum::Superpositions provides this in a more flexible way by adding the
'any' and 'all' keywords.
http://search.cpan.org/doc/DCONWAY/Quantum-Superpositions-1.03/lib/Quantum/
Superpositions.pm
One of Damian Conway's many promised RFCs will cover incorporating these
ideas into Perl 6.
RE: $a in @b
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
Garrett
Re: $a in @b
On Wed, Sep 06, 2000 at 09:43:03AM -0500, Garrett Goebel wrote:
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Fwd: RE: $a in @b
The fact that something can be accomplished in Perl doesn't necessarily mean
its the best or most desirable way to do it. I respect the programming
abilities, but
grep { ref($a) eq ref($b) } @b)
is far less intuitive than the proposal. I could perhaps dig into my distant
memory and explain how to accomplish something like this with PDP-8
front-panel switches, but that doesn't mean that we should not attempt a
loftier solution.
IMHO Perl should add a plethora of higher-order functions for arrays and
hashes, and from the chatter here I think a lot of people agree. Put them
there and if people don't want to use them, fine. Give us lots of ways to do
things- we know that's Perlish.
Personally, I don't like the "in" choice- I favor symbols over words, but
its better than not having it at all. Conflicts with barewords, especially
in hash refs, can be a problem. Do away that the conflict by favoring
symbols over words.
Ed
-
From: Garrett Goebel [EMAIL PROTECTED]
To: 'Jonas Liljegren' [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: $a in @b
Date: Wed, 6 Sep 2000 09:43:03 -0500
From: Jonas Liljegren [mailto:[EMAIL PROTECTED]]
Does any other RFC give the equivalent to an 'in' operator?
I have a couple of times noticed that beginners in programming want to
write if( $a eq ($b or $c or $d)){...} and expects it to mean
if( $a eq $b or $a eq $c or $a eq $d ){...}.
I think it's a natural human reaction to not be repetative. An 'in'
operator will help here. It could be something like this:
$a in @b; # Has @b any element exactly the same as $a
$a == in @b; # Is any element numericaly the same as $a
$a eq in @b;
$a in @b; # Is $a bigger than any element in @b?
$a not in @b; # Yes. Make 'not' context dependent modifier for in.
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
(grep { $a != $_ } @b) == @b)
Garrett
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Re: $a in @b
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
--tom
Re: Fwd: RE: $a in @b
IMHO Perl should add a plethora of higher-order functions for arrays and hashes, and from the chatter here I think a lot of people agree. Make some modules, release them, and see how much they're used. Then one can contemplate sucking them into the core based upon the success of those modules. --tom
Re: $a in @b
On Wed, Sep 06, 2000 at 09:46:13AM -0600, Tom Christiansen wrote:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
Agreed, that would be very natural.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: $a in @b
Garrett Goebel wrote:
grep { ref($a) eq ref($b) } @b) # Same type?
grep { $a == $_ } @b)
grep { $a eq $_ } @b)
grep { $a $_ } @b)
Garrett
grep doesn't short-circuit; you can't return or exit or last out
of the thing.
Maybe we could add support for Clast to Cgrep and Cmap: that
would allow a shorter Cin function without losing any flexibility.
grep { ref($a) eq ref($b) and last } @b) # Same type?
grep { $a == $_ and last } @b)
grep { $a eq $_ and last } @b)
grep { $a $_ and last } @b)
The RFC 88 lazy would work too, you can pull off the first grepped
value and if you don't go back for another the thing will get dismantled
when the current scope closes.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: $a in @b
Does any other RFC give the equivalent to an 'in' operator?
RFC 22 offers:
switch ($a) {
case (@b) { ... }
}
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a != any(@b) ) { ... }
and:
if (any(@a) == any(@b) ) { ... }
and:
if (all(@a) eq any(@b) ) { ... }
etc.
which I think is by far the cleanest solution. :-)
Damian
Re: $a in @b
Damian Conway [EMAIL PROTECTED] writes:
Does any other RFC give the equivalent to an 'in' operator?
and my forthcoming superpositions RFC will offer:
if ($a == any(@b) ) { ... }
and:
if ($a eq any(@b) ) { ... }
and:
if ($a != any(@b) ) { ... }
and:
if (any(@a) == any(@b) ) { ... }
and:
if (all(@a) eq any(@b) ) { ... }
etc.
which I think is by far the cleanest solution. :-)
Yes. That's exactly what I was looking for.
=)
--
/ Jonas - http://jonas.liljegren.org/myself/en/index.html
RE: $a in @b
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
On Wed, 06 Sep 2000 13:04:51 -0500, David L. Nicol 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.
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use last within
a grep or map block, then further processing for that element of the list
which grep is working on would be skipped, and it would continue with the
next element.
would leave
@passed = (1, 2)
instead of the current behaviour which would be
@passed = (1, 2, 2, 1)
You can also do:
{
last;
}
We are already advised not to use last within eval {}, sub {}, do {}, grep
{}, and map {}, but this might break some obfuscated code which depends on
it. I'm not to sure how this could be handled in a Perl 5-6 translation...
to exit a block...
Hmm... I guess I'll submit and RFC on this...
Garrett
RE: $a in @b
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use
last within a grep or map block, then further processing for that
element of the list which grep is working on would be skipped, and
it would continue with the next element.
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 the Clast is
executed, which terminates the Cgrep immediately.
instead of the current behaviour which would be
@passed = (1, 2, 2, 1)
That's not the current behaviour.
With the Clast you either get an exception or an exit from the surrounding
block (and in either case @passed is not reassigned at all).
If you meant "current behaviour without the Clast", that's still
not right. Without the Clast the current behaviour leaves (1,1)
in @passed.
We are already advised not to use last within eval {}, sub {}, do
{}, grep {}, and map {}, but this might break some obfuscated code
which depends on it. I'm not to sure how this could be handled in a
Perl 5-6 translation...
Have p52p6 name *every* block and label *every* Cnext, Clast, and Credo.
Damian
