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 C/C/C?
>
> What, you mean like
>
> Loop controls don't work in an C or C, either, since
> those aren't loops. But you can always introduce an extra set
> of braces to give yourself a bare block, which I 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 C 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)
>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 C/C/C?
What, you mean like
Loop controls don't work in an C or C, either, since
those aren't loops. But you can always introduce an extra set
of braces to give yourself a bare block, which I 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: 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 C/C/C?
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 C control implemented as macro for throwing
an exception that is caught and handled by a subroutine? I.e., is there a
parallel between how C/C/C and C are implemented?
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 K&P: "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)
On Thu, Sep 14, 2000 at 11:46:31AM -0400, 'John Porter' wrote: > Jarkko Hietaniemi wrote: > > > In the other camp, C has been suggested; but > > > the conflation of that with its thread-related semantics may not > > > be a such good idea. > > > > C. > > 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)
Jarkko Hietaniemi wrote: > > In the other camp, C has been suggested; but > > the conflation of that with its thread-related semantics may not > > be a such good idea. > > C. 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)
> 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 C; I have been more of the > opinion that a grep block is more like a sub, and so should use > C. In the other camp, C has been suggested; but > the conflation of that with its thread-related semantics may not > be a such good idea. C. -- $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:
> "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 C; I have been more of the
opinion that a grep block is more like a sub, and so should use
C. In the other camp, C 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)
"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)
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 C, C, or C 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 C, C, C, C, C, 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)
> "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]> 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 (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 C, C, C, C, and C? 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
(C, C, or C) 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 C 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 C and C. I have no idea why it is evaluated
before the loop condition... That seems un-DWIMish.
Garrett
Re: $a in @b (RFC 199)
I wrote: > > I can count how many times I've wanted to -- and thought s/can/can't/. :-o -- John Porter
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 C
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 (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)
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 (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 (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)
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 C spelled C in Perl5?
> > (Except, of course, that C inside a C does a whole lot
> > more nowadays).
>
> And except that C 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 C would be a useful in the context of C
and C. But it doesn't solve the problem (RFC 199) of short-circuiting
C and C if you have no intention of preserving state.
grep { 1 } 1..1_000_000;
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
> C explicitly to mean "no further iterations" is highly
> counterintuitive, or at least inconsistent.
