Re: Control flow variables

2003-11-18 Thread Larry Wall
On Tue, Nov 18, 2003 at 11:14:54AM -0500, Dan Sugalski wrote: : On Tue, 18 Nov 2003, Simon Cozens wrote: : : > [EMAIL PROTECTED] (Austin Hastings) writes: : > > This is what I was talking about when I mentioned being able to do: : > > &cleanup .= { push @moves: [$i, $j]; } : > : > This reminds m

Re: syntax: multi vs. method

2003-11-18 Thread Luke Palmer
Larry Wall writes: > If you write: > > multi method add( $self: Foo $foo, Bar $bar ); > > then there are multiple add methods in the current class. Note the > invocant is not optional in this case. Also, there's an implied > second colon after $bar, indicating the end of the arguments to be

Re: [perl] Re: syntax: multi vs. method

2003-11-18 Thread Joe Gottman
- Original Message - From: "Jonathan Lang" <[EMAIL PROTECTED]> > So the following three declarations cover very similar (but not quite > identical) things: > > multi sub call ($a: $b) {...} > submethod invoke ($a: $b) {...} > method check ($a: $b) {...} > > All three of these use mu

Re: [perl] RE: s/// in string context should return the string

2003-11-18 Thread Joe Gottman
- Original Message - From: "Austin Hastings" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 18, 2003 3:04 PM Subject: [perl] RE: s/// in string context should return the string > As a "Bvalue" where possible, so they can cascade and nest. Exc

Re: syntax: multi vs. method

2003-11-18 Thread Larry Wall
I think most everyone is missing the new simplicity of the current conception of "multi". It's now completely orthogonal to scoping issues. It merely says, "I'm putting multiple names into a spot that would ordinarily demand a unique name." In other words, what a name means in a given scope is a

Re: syntax: multi vs. method

2003-11-18 Thread Damian Conway
Jonathan Lang wrote: multi sub call ($a, $b: $c) {...} multi submethod invoke ($a, $b: $c) {...} multi method check ($a, $b: $c) {...} Why do we suddenly need to append the "multi" keyword to "submethod" and "method"? So the compiler knows we really did mean for that (sub)method to be multip

Re: Control flow variables

2003-11-18 Thread David Wheeler
On Tuesday, November 18, 2003, at 06:44 PM, Joseph Ryan wrote: And also if @array_of_random_values contains 'ok'. D'oh! See Damian's solution, then. ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://w

Re: Control flow variables

2003-11-18 Thread Damian Conway
David Wheeler wrote: Isn't that just: for @array_of_random_values_and_types, 'ok' -> $t { when 'ok' { yada(); last } last unless some_sort_of_test($t); } IOW, the topic is only 'ok' when all of the items in the array have been processed Unless, of course, the string 'ok'

Re: Control flow variables

2003-11-18 Thread Joseph Ryan
David Wheeler wrote: On Tuesday, November 18, 2003, at 06:11 PM, Joseph Ryan wrote: Not to be a jerk, but how about: my $is_ok = 1; for @array_of_random_values_and_types -> $t { if not some_sort_of_test($t) { $is_ok = 0; last; } } if $is_ok {

Re: Control flow variables

2003-11-18 Thread David Wheeler
On Tuesday, November 18, 2003, at 06:11 PM, Joseph Ryan wrote: Not to be a jerk, but how about: my $is_ok = 1; for @array_of_random_values_and_types -> $t { if not some_sort_of_test($t) { $is_ok = 0; last; } } if $is_ok { yada() # has sideef

Re: Control flow variables

2003-11-18 Thread Damian Conway
Joseph Ryan wrote: Not to be a jerk, but how about: my $is_ok = 1; for @array_of_random_values_and_types -> $t { if not some_sort_of_test($t) { $is_ok = 0; last; } } if $is_ok { yada() # has sideeffects... } That's just: given @array_

Re: Control flow variables

2003-11-18 Thread Joseph Ryan
Damian Conway wrote: Seiler Thomas wrote: So... lets call a function instead: my $is_ok = 1; for 0..6 -> $t { if abs(@new[$t] - @new[$t+1]) > 3 { $is_ok = 0; last; } } if $is_ok { yada() # has sideeffects... } That's just:

Re: syntax: multi vs. method

2003-11-18 Thread Jonathan Lang
Luke Palmer wrote: > Jonathan Lang writes: > > Luke Palmer wrote: > > > Well, "multi" is no longer a declarator in its own right, but rather > > > a modifier. Synopsis & Exegesis 6 show this. > > > > I don't know about Exegesis 6, > > Then you should probably read it. It is the most recent o

Re: Control flow variables

2003-11-18 Thread Damian Conway
Seiler Thomas wrote: So... lets call a function instead: my $is_ok = 1; for 0..6 -> $t { if abs(@new[$t] - @new[$t+1]) > 3 { $is_ok = 0; last; } } if $is_ok { yada() # has sideeffects... } That's just: for 0..6, 'ok' -> $

Re: Control flow variables

2003-11-18 Thread Seiler Thomas
Damian Conway wrote: > push @moves, [$i, $j]; > for 0..6 -> $t { > if abs(@new[$t] - @new[$t+1]) > 3 { > pop @moves; > last; > } > } > > Indeed, an elegant way around the problem. So... lets call a function instead: my $is_ok = 1;

RE: Control flow variables

2003-11-18 Thread Dan Sugalski
On Tue, 18 Nov 2003, Austin Hastings wrote: > > > > -Original Message- > > From: Dan Sugalski [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 18, 2003 4:34 PM > > To: Language List > > Subject: RE: Control flow variables > > > > > > On Tue, 18 Nov 2003, Austin Hastings wrote: > > > >

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Dan Sugalski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 4:34 PM > To: Language List > Subject: RE: Control flow variables > > > On Tue, 18 Nov 2003, Austin Hastings wrote: > > > This seems excessive, but easily discarded during optimization.

Re: Control flow variables

2003-11-18 Thread Damian Conway
Luke Palmer wrote: My C/C typo may have misled you, but the original example pushed only if *none* of them passed the condition. Ah, sorry, I misunderstood. So you want: push @moves, [$i, $j]; for 0..6 -> $t { if abs(@new[$t] - @new[$t+1]) > 3 { pop @moves;

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Austin Hastings writes: > > From: Luke Palmer [mailto:[EMAIL PROTECTED] > > > > Austin Hastings writes: > > > > From: Michael Lazzaro [mailto:[EMAIL PROTECTED] > > > > > > > > Would that then imply that > > > > > > > > sub blah { > > > >... # 1 > > > >return if $a;

RE: Control flow variables

2003-11-18 Thread Dan Sugalski
On Tue, 18 Nov 2003, Austin Hastings wrote: > This seems excessive, but easily discarded during optimization. On the other > hand, I don't trust the "last statement evaluated" behavior for loops, since > the optimizer could very well do surprising things to loop statements. > (Likewise, however, f

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 3:11 PM > To: Austin Hastings > Cc: Michael Lazzaro; [EMAIL PROTECTED] > Subject: Re: Control flow variables > > > Austin Hastings writes: > > > > > > > -Original Message- > >

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Damian Conway [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 4:02 PM > To: Language List > Subject: Re: Control flow variables > > > Luke Palmer started a discussion: > > > > I see this idiom a lot in code. You loop through some values on a > >

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Damian Conway writes: > Luke Palmer started a discussion: > > > >I see this idiom a lot in code. You loop through some values on a > >condition, and do something only if the condition was never true. > >$is_ok is a control flow variable, something I like to minimize. Now, > >there are other way

Re: Control flow variables

2003-11-18 Thread Damian Conway
Michael Lazzaro wrote: So, just to make sure, these two lines are both valid, but do completely different things: return if $a; Means: if ($a) { return } return if $a { $a } Means: if ($a) { return $a } else { return undef } Damian

Re: Control flow variables

2003-11-18 Thread Damian Conway
Luke Palmer started a discussion: I see this idiom a lot in code. You loop through some values on a condition, and do something only if the condition was never true. $is_ok is a control flow variable, something I like to minimize. Now, there are other ways to do this: if (0..6 ==> grep -> $

Re: Control flow variables

2003-11-18 Thread Michael Lazzaro
Would that then imply that sub blah { ... # 1 return if $a;# 2 ... # 3 } ...would return $a if $a was true, and fall through to (3) if it was false? It sure should, provided there were a correct context waiting, which would quite nicel

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Austin Hastings writes: > > > > -Original Message- > > From: Michael Lazzaro [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 18, 2003 2:06 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Control flow variables > > > > > > > > On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wr

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Austin Hastings writes: > > > > -Original Message- > > From: Michael Lazzaro [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 18, 2003 2:06 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Control flow variables > > > > > > > > On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wr

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Michael Lazzaro [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 2:06 PM > To: [EMAIL PROTECTED] > Subject: Re: Control flow variables > > > > On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote: > > Given that we've introduced the conce

RE: s/// in string context should return the string

2003-11-18 Thread Austin Hastings
As a "Bvalue" where possible, so they can cascade and nest. =Austin > -Original Message- > From: Stephane Payrard [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 12:19 PM > To: [EMAIL PROTECTED] > Subject: s/// in string context should return the string > > > s/// in strin

Re: Control flow variables

2003-11-18 Thread Michael Lazzaro
On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote: Given that we've introduced the concept of "if" having a return status: my $result = if ($a) { $a } else { $b }; Would that then imply that sub blah { ... # 1 return if $a;# 2 ...

Re: Control flow variables

2003-11-18 Thread Mark A. Biggar
OOPS, totally miss-read your code, ignore my first part of my last message. -- [EMAIL PROTECTED] [EMAIL PROTECTED]

Re: Control flow variables

2003-11-18 Thread Mark A. Biggar
Luke Palmer wrote: I was reading the most recent article on perl.com, and a code segment reminded me of something I see rather often in code that I don't like. Here's the code, Perl6ized: ... ; my $is_ok = 1; for 0..6 -> $t { if abs(@new[$t] - @new[$t+1]) > 3 { $is_

s/// in string context should return the string

2003-11-18 Thread Stéphane Payrard
s/// in string context should return the string after substituion. It seems obvious to me but I mention it because I can't find it in the apocalypses. -- stef

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 10:49 AM > To: Austin Hastings > Cc: Language List > Subject: Re: Control flow variables > > > Austin Hastings writes: > > Luke Palmer wrote: > > > I was reading the most recent articl

Re: Control flow variables

2003-11-18 Thread Dan Sugalski
On Tue, 18 Nov 2003, Simon Cozens wrote: > [EMAIL PROTECTED] (Austin Hastings) writes: > > This is what I was talking about when I mentioned being able to do: > > &cleanup .= { push @moves: [$i, $j]; } > > This reminds me of something I thought the other day might be useful: > > $cleanup = b

Re: Control flow variables

2003-11-18 Thread Simon Cozens
[EMAIL PROTECTED] (Austin Hastings) writes: > This is what I was talking about when I mentioned being able to do: > &cleanup .= { push @moves: [$i, $j]; } This reminds me of something I thought the other day might be useful: $cleanup = bless {}, class { method DESTROY { ... } }

Re: Control flow variables

2003-11-18 Thread Dan Sugalski
On Tue, 18 Nov 2003, Simon Cozens wrote: > [EMAIL PROTECTED] (Dan Sugalski) writes: > > > Luke Palmer: > > > > That's illegal anyway. Can't chain statement modifiers :-) > > Will be able to. > > I thought as much; Perl 6 will only be finally finished when the biotech > is sufficiently advanced to

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Austin Hastings writes: > Luke Palmer wrote: > > I was reading the most recent article on perl.com, and a code segment > > reminded me of something I see rather often in code that I don't like. > > Here's the code, Perl6ized: > > > > ... ; > > my $is_ok = 1; > > for 0..6 -> $t { > >

RE: Control flow variables

2003-11-18 Thread Austin Hastings
> -Original Message- > From: Luke Palmer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 9:21 AM > To: Language List > Subject: Control flow variables > > > I was reading the most recent article on perl.com, and a code segment > reminded me of something I see rather often i

Re: Control flow variables

2003-11-18 Thread Simon Cozens
[EMAIL PROTECTED] (Dan Sugalski) writes: > > Luke Palmer: > > > That's illegal anyway. Can't chain statement modifiers :-) > Will be able to. I thought as much; Perl 6 will only be finally finished when the biotech is sufficiently advanced to massively clone Larry... -- Sometimes it's better n

Re: Control flow variables

2003-11-18 Thread Dan Sugalski
On Tue, 18 Nov 2003, Simon Cozens wrote: > Luke Palmer: > > That's illegal anyway. Can't chain statement modifiers :-) > > Bah, should be able to! Will be able to. Dan --"it's like this"--- Dan Sugalsk

Re: Control flow variables

2003-11-18 Thread Simon Cozens
Luke Palmer: > Well... it is and isn't. At first sight, it makes the language look > huge, the parser complex, a lot of syntax to master, etc. It also seems > to me that there is little discrimination when adding new syntax. Correct. > But I've come to look at it another way. Perl 6 is doing

Re: Control flow variables

2003-11-18 Thread Luke Palmer
Simon Cozens writes: > [EMAIL PROTECTED] (Luke Palmer) writes: > > I was reading the most recent article on perl.com, and a code segment > > reminded me of something I see rather often in code that I don't like. > > The code in question got me thinking too; I wanted to find a cleaner > way to writ

Re: Control flow variables

2003-11-18 Thread Simon Cozens
[EMAIL PROTECTED] (Luke Palmer) writes: > I was reading the most recent article on perl.com, and a code segment > reminded me of something I see rather often in code that I don't like. The code in question got me thinking too; I wanted to find a cleaner way to write it, but didn't see one. > So,

Control flow variables

2003-11-18 Thread Luke Palmer
I was reading the most recent article on perl.com, and a code segment reminded me of something I see rather often in code that I don't like. Here's the code, Perl6ized: ... ; my $is_ok = 1; for 0..6 -> $t { if abs(@new[$t] - @new[$t+1]) > 3 { $is_ok = 0;

Re: syntax: multi vs. method

2003-11-18 Thread Luke Palmer
Jonathan Lang writes: > My apologies for the break in the chain of responses; I lost your reply > before I could reply to it, and had to retrieve it from the list archives. > > > Luke Palmer wrote: > > Well, "multi" is no longer a declarator in its own right, but rather a > > modifier. Synopsis