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 > >

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 c

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 > "sa

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

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

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 > >

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

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 o

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

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

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

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

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 >

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

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 enclosin

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 differen

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 f

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! perha

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

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 o

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

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

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 > >

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 >

Re: $a in @b

> DC> I would propose that the C 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'?

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 (

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 = > I

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 pl

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.

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

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

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, i

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. Af

Re: $a in @b

Ariel Scolnicov wrote: > > 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). Hopefully, what C does in grep in perl6 will be different from perl5. -- John Porter We're building the house of the future toget

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 > othe

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

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 C spelled C in Perl5? Ariel> (Except

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

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

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"

Re: $a in @b

> Quantum::Superpositions provides this in a more flexible way by adding the > 'any' and 'all' keywords. > > Superpositions.pm> > > One of Damian Conway's many promised RFCs will cover in

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 suggeste

Re: $a in @b

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> I would propose that the C 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: Wh

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 bl

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 distan

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 C and C.

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 > > C blocks. I'm for putting it after a comma. Which matches the synt

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

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

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 th

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

Damian Conway wrote: > >> > I would propose that the C operation should short-circuit if the >> > block throws an exception, with the value of the expection determining >> > whether the final invocation of the block should accept the element it >> > was filtering: >> >> Ot

Re: $a in @b

> I don't think C should be able to eat unintentional exceptions. > Perhaps it could short-circuit if the exception is 1 or false, as > opposed to true or false? No objection here. Damian

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 > C blocks. I'm for putting it after a comma. Which matches the syntax of > John Porter's proposal about internally converting the block to a

Re: $a in @b

On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote: > I would propose that the C operation should short-circuit if the > block throws an exception, with the value of the expection determining > whether the final invocation of the block should accept the element it > was filtering: I do

Re: $a in @b

Damian Conway wrote: > A C such as: > > @array = grep BLOCK LIST > > is equivalent to: > > @tmp = (); > foreach (LIST) { push @tmp, $_ if do BLOCK } > @array = @tmp; > > That similarity would not change in any way under the proposal > (except to be made stronge

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

Re: $a in @b

> > I would propose that the C operation should short-circuit if the > > block throws an exception, with the value of the expection determining > > whether the final invocation of the block should accept the element it > > was filtering: > > Otherwise nice but until now die() ha

Re: $a in @b

> I would propose that the C operation should short-circuit if the > block throws an exception, with the value of the expection determining > whether the final invocation of the block should accept the element it > was filtering: Otherwise nice but until now die() has been a serious thing, now it

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 C and C. Let's take a step back and an

Re: $a in @b

Damian Conway wrote: > > The expression C<1 and last> does *not* evaluate to true -- it does not > evaluate to *anything*. So the C is terminated by the C > without the block having ever evaluated true. So no element of LIST is > ever "passed through". So the C evaluates to zero. Right. Well, pe

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 elim

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 C > >lets through a specific value" ugly: > > > >my $seen; > >$has_odd_elem = grep { $seen && last; $_%2 && ++$s

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 C >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

John wrote: > > I don't know how grep works internally. I don't know if grep pushes > > elements into @a one at a time, or if it returns a finished list of > > elements which pass the conditional block. If it is the latter as I > > assume, a short-circuited grep would return a list o

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,

Re: $a in @b

Bart wrote: > >The last operator doesn't return anything does it? It immediately > >exits the loop/block in question. This is correct. > But then, what is the value that would be returned to grep()? If you use > 0 as the last value evaluated inside the block, grep() would return an

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 C's block were terminated by a call to C, > grep immediately returns the last block value (i.e. C > on the first block call, $_[0] otherwise). Or maybe that's @_ > otherwise...

RE: $a in @b

From: Bart Lateur [mailto:[EMAIL PROTECTED]] > > On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote: > >> > grep { $a > $_ and last } @b) > >> > >> So "last" should return true, or what? > > > >The last operator doesn't return anything does it? It > >immediately exits the loop/block

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 retur

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 th

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

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. @p

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: >

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

> 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

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 C to C

Re: Fwd: RE: $a in @b

Ed Mills wrote: > 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. ...and is an example of

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/jh

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

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 modul

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

Fwd: RE: $a in @b

efs, 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] >S

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 $

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 ){...

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.) >

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 natura