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: "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)
'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)
"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 (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
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)
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 (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
"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
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 :-)
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.
--
#!/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 Setting Orange, the 36th of Bureaucracy, in the YOLD 3166:
Science is a two headed beast, arthur. One head is good. It brings us advances like
aspirin. But the other head-Oh, beware the other head of science, arthur! It bites!
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
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
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: 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
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 (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
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
"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
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.
I don't quite see yeild as being that. I think more in terms of driving a car.
Give precedence to someone else but keep running, either way not quite the
best word... not bad but not optimium (if you're into making the word mean
what it does)
What about feign?
feign \'fa-n\ vb [ME feignen, fr. OF feign-, stem of feindre, fr. L
fingere] to shape, feign - more at DOUGH 1a: to represent by a false
appearance of : SHAM 1b: to assert as if true : PRETEND archaic 2a:
INVENT, IMAGINE 2b: to give fictional representation to obs 3: DISGUISE,
CONCEAL : PRETEND, DISSEMBLE - feign.er n
This is a nice general word, and this keyword could be used elsewhere as
well... How about "a general means of short-circuting a block"?
skip is another word, but it seems to connote a loop. and we already have
words for those.
--
#!/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
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
"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
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. The weird "scalar arrays" (AKA piddles) in PDL have provided 'any' and 'all' in very much this way for almost a year now (since 2.003), see http://pdl.sourceforge.net/PDLdocs/Primitive.html#any Christian
Re: $a in @b
On Thu, Sep 07, 2000 at 07:44:31PM -0500, Jarkko Hietaniemi wrote: 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? I think you may be right. Graham.
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
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
John wrote:
I don't know how grep works internally. I don't know if grep pushes
elements into @a one at a time, or if it returns a finished list of
elements which pass the conditional block. If it is the latter as I
assume, a short-circuited grep would return a list 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".
This is correct, but the phrase "...up to the point..." is ambiguous.
See below.
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.
My understanding would be that that is not so.
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.
Damian
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
Garrett wrote:
It almost feels like grep could have been written like this (in
another life): @a = grep (@b) { $_ 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
While I'm at it, I'm curious as to why:
$a = 2;
@b = (1, 2, 3, 2, 1));
@a = grep({ { $_ $a and last} } @b);
results in an exception?
You mean, apart from the two syntax errors? ;-)
It's because the DWIMmer interprets the block:
{ { $_ $a and last} }
as an anonymous block (the outer braces) containing an anonymous hash
constructor (the inner braces). Try this instead:
{ for(1){ $_ $a and last} }
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
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... No. Cdie has for a long time now been the exception throwing mechanism as well. Nowadays Cdie is only "serious" if you're too lazy to catch the exceptions it throws. This proposal just suggests that Cgrep, Cmap, etc. should catch exceptions emanating from their control BLOCKs and act on them. :-) Damian
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
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
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
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:
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...
No. Cdie has for a long time now been the exception throwing mechanism
as well. Nowadays Cdie is only "serious" if you're too lazy to catch the
exceptions it throws.
This proposal just suggests that Cgrep, Cmap, etc. should catch
exceptions emanating from their control BLOCKs and act on them. :-)
Damian
Ick.
From the standpoint of die() being something serious and fatal unless
caught, this weakens die() considerably, because you'll need to do
another die() after the grep or map or whatever.
From the standpoint of die() being the exception throwing mechanism,
this weakens die() considerably because lots of things can now catch
your exceptions, and if you want to be sure they get propagated all the
way up to the appropriate handler, you have to keep re-throwing the damn
things.
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
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.
To get small numbers and primes, use
@list = grep { goto ACCEPT if isprime($_); $_ 10 } 0..100;
or, equivalently,
@list = grep { next ACCEPT if isprime($_); $_ 10 } 0..100;
and to produce qw(bed feed feed): (new capability)
@list = grep { /e/g and redo ACCEPT } qw(cat bed dish feed)
A bare 'last' within such a block would be, implicitly, 'last REJECT'.
Or leave it an error?
You wouldn't be able to escape the innermost enclosing grep or map with
this. I'm not sure if that's good or bad.
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
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the expected way, so you use
($first_small) = grep { ($_ 2) and last ACCEPT } @list.
I considered this solution, but rejected it precisely because...
You wouldn't be able to escape the innermost enclosing grep or map
with this. I'm not sure if that's good or bad.
Bad, I think.
Damian
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
Damian Conway wrote:
Both are pretty much the same. Combining them, I'd say that exceptions
should remain exceptional.
I'd say short-circuiting a vector operation was exceptional enough. :-)
I'd say it's exceptional sometimes, and very ordinary other times, and
I'd prefer to be the one deciding which is which.
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.
I considered this solution, but rejected it precisely because...
You wouldn't be able to escape the innermost enclosing grep or map
with this. I'm not sure if that's good or bad.
Bad, I think.
I'm not so sure about that. And note that any die()-related proposal
doesn't give you multilevel exits either.
But if it's necessary, I suppose you could always make
Loop1Accept:Loop1Reject: grep {
Loop2Accept:Loop2Reject: map { ... }
}
work. Though those labels really aren't in the right place.
grep { ... } @list accept1: reject1: ;
is an idea. I'd probably pick
loop1: grep { ... last ACCEPT(loop1) } @list
over either of those, though.
In the back of my mind, I keep thinking that it would be cool to have
similar control over the flip-flop operator too. I can never remember
whether Cprint if /foo/ .. /bar/ will print the line containing "bar"
or not, but half the time I want the other one. But I doubt that's
related enough to tie into this.
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
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
On Wed, Sep 06, 2000 at 10:40:47AM +0200, Jonas Liljegren wrote:
(I sent this to horos in the first RFC format, before the language
list. I haven't got any response, so I send this agian now. I don't
have time to read the list or maintain an RFC. I just wan't to give
this suggestion.)
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 one of Damian's proposes any()
if ($a eq any($b,$c,$d)) { ... }
Graham.
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: Fwd: RE: $a in @b
Tom Christiansen [EMAIL PROTECTED] writes: 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. Agreed, with one caveat. Damian's posited C^foo currying magic should go in the core because it makes all the other functional stuff *so* much easier to do, and it's a tad tricky to implement in a module. -- Piers
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
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?
You do need a true value for grep() to claim success.
--
Bart.
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
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
